我用 Quiver 记技术笔记快 10 年了。
这些年陆续记下了 Java、Python、MySQL、Linux、算法、软考等内容，数量接近一千篇。刚开始笔记不多，Quiver 的「笔记本 + 标签」很好用：内容放进对应分类，需要时再按目录或者全局找出来。
但笔记积累到一定数量后，原来的分类方式开始失效。
比如算法相关的内容，被我分别放在 python算法、剑指offer-python 和 算法 里；和高并发有关的内容，则散落在 MySQL、Redis、消息队列和分布式事务等不同目录中。单看每个目录都没问题，真正要解决一个具体问题时，却经常需要在多个地方来回翻找。
另一个问题是旧笔记越来越多。很多内容早已过时，但逐篇检查和整理的成本很高。它们还在知识库里，却很少再被找到，慢慢变成了「数字垃圾」。
我最终决定从 Quiver 迁移到 Obsidian。目的不只是换一个笔记软件，而是借这次机会重新整理这些笔记，让它们更容易被搜索、关联和继续维护。
最近在维护一个 Go 项目时，遇到了一个关于 go mod tidy 的棘手问题。表面现象很简单：执行命令后，终端要么卡在下载某个包的过程中一动不动，要么直接报错 unknown revision。
这个报错看起来像是版本号写错了，但真正麻烦的地方在于，它背后可能隐藏着一连串问题——网络、代理、间接依赖、版本冲突，每个环节都有可能出问题。
这篇文章把这次完整的排查过程记录下来，重点讲四件事：
最近踩了一个谷歌支付相关的坑，表面现象很简单：服务端在查询订单或校验支付结果时，接口直接报错：
|
|
这个报错如果只看字面，很容易理解成“账号权限不够”，但真正麻烦的地方在于，它并不会直接告诉你到底是：
这篇文章就把这次问题完整记一下，重点讲三件事：
最近遇到一个挺绕的接口问题：Postman 请求状态码明明是 200，但就是没有响应数据，同时还会报一个看起来很奇怪的错误：
|
|
一开始看到这个报错，很容易怀疑是服务端没启动、返回体格式不对，甚至是接口代码本身有异常。但这次真正的问题，不在业务逻辑，而是在“测试环境请求链路 + 压缩编码 + 代理转发”这几个环节叠在了一起。
这篇文章就把这次排查过程完整梳理一下，重点讲清楚这几个问题：
curl 能正常返回，而 Postman 不行content-encoding: br最近折腾了一次 H5 项目的上线，原本以为这种纯前端静态项目会很简单，结果真正麻烦的地方根本不在打包，而是在部署链路上：S3 目录权限、CloudFront 的 SPA 回退、Cloudflare 的域名解析切换、还有 App 内 WebView 的缓存问题。
这篇文章就把这次完整过程整理一下，专门讲如何通过 Amazon S3、CloudFront 和 Cloudflare 部署 H5 项目，以及上线过程中最容易踩的坑和对应处理方式。