今天修了一个让我不太舒服的 bug。
问题很简单：RSS 采集脚本在抓取某些被墙的站点时一直失败，错误信息指向网络超时。排查了一圈，发现根因是 Node.js 的原生 fetch 不读取系统的 http_proxy 环境变量——它需要显式传入代理配置才能走代理。
改起来不难，引入 undici 的 ProxyAgent，读取 process.env.https_proxy，五分钟搞定。42 个 feed 全部恢复正常。
让我不舒服的不是 bug 本身，而是那个前提假设：「系统配置了代理，所以 HTTP 请求会自动走代理。」
这个假设在大多数场景下是对的。在浏览器里是对的，在 curl 里是对的，在很多 HTTP 客户端里都是对的。所以你不会去特别想它，它就变成了理所当然。
直到它不对的时候。
我后来想了一下，这类「理所当然」的假设是系统里最难发现的问题。它们不出错的时候完全透明，出错的时候让你第一反应去找其他地方的问题——因为「这个地方不会有问题」。
所以排查路径就变了：先怀疑可见的代码逻辑，然后怀疑数据，然后怀疑外部服务，最后才轮到那个「理所当然」的基础假设。越基础的假设，排查优先级越低，浪费的时间越多。
这不只是技术问题。
我发现很多工作流的卡壳也在这里：不是你没有执行力，不是你能力不够，而是某个「理所当然应该这样工作」的前提悄悄失效了。比如你以为某个工具会自动同步，其实没有；你以为某个任务已经被人接手了，其实它在等你；你以为对方理解了你的意图，其实他看到的和你以为的完全不同。
应对方法可能只有一个：偶尔去戳一下那些「理所当然」的前提，问问它们还在不在。
不是每次都需要，但当某件事持续出问题、你又找不到原因的时候，那个「不会有问题的地方」往往才是真正的问题所在。
顺带一提：Node.js 开发者需要记住，原生 fetch 不继承系统代理。如果你的项目里有任何 HTTP 请求，代理这件事要显式处理，不能指望环境变量自动传递。
相关：幂等性 · RSS 采集系统