某个项目的图片资源一直放在 AWS S3，再通过 CloudFront 对外分发。用户上传的图片、业务封面图虽然在 App 端做了裁剪和压缩，但还是顶不住原图本身体积大。需要查看原图时没有问题，列表页、详情页和图片墙也一直加载这些大图，就有点浪费了。
访问量上来以后，CloudFront 的出站流量也跟着涨。这个问题和图片能不能正常访问没关系，主要还是日常页面根本用不到原始尺寸，却一直在传原图。
针对这种情况，我用 Lambda@Edge 做了一套按需生成缩略图的方案。原图继续保留，前端通过查询参数指定目标尺寸；没有指定参数的高频接口，则默认给图片地址带上缩略图参数。缩略图第一次访问时生成，后面交给 CloudFront 和单独的 S3 桶缓存。
经观察，上线后看了一周，CDN 出站流量大约少了三分之二。
我用 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