16 年的 SQLite 老 Bug 现形记：Tailscale 这篇排障实录值得读三遍

一个藏了 16 年的 SQLite Bug，被 Tailscale 的工程师揪出来了，复盘帖在 HN 上拿下一千多赞。WAL 日志重置的边界 case，平时不犯病，一犯就是大事。这篇把高手的排障思路讲成中文，抄的是方法，不是代码。

先说结论：老 Bug 难的不是修，是定位。16 年没人碰到，不代表不存在，只代表触发条件苛刻。Tailscale 团队赢在三件事：能稳定复现、有耐心看底层、不放过任何“这不应该啊”的瞬间。排障的本质，是把“灵异事件”变成“必现用例”。

高手的四步值得抄。第一步，缩小范围，先确认是自己的锅还是底层的锅，二分法定位到具体组件。第二步，读源码，SQLite 这种久经考验的项目，文档和注释就是地图，顺着 WAL 重置的逻辑走。第三步，造复现，写最小用例让 Bug 每次都出现，复现不了就谈不上修。第四步，向上游报，修完给社区交回去，全世界都受益。

为什么 SQLite 值得学，有三点。它是全世界部署最广的数据库，你的手机、浏览器里都有它，读它的 Bug 等于上免费大师课。它的代码以注释详尽著称，排障过程本身就是教材。它的社区响应快，好补丁不会被埋没，贡献一次简历增光。多说一句：复盘文化是最好的团队资产。每次大坑都写下来，半年后就是新人的避坑指南。你们团队有复盘的习惯吗？

中国开发者照抄就行：下次碰到“不可能”的 Bug，别急着绕过去，先问是不是底层在作怪。复现用例写下来，源码翻开看，修完记得回馈社区。这三板斧， junior 和 senior 的差距就藏在这里。

行动建议：收藏这篇复盘，找个周末跟着它的思路走一遍，哪怕不求甚解，也能学到排障的章法。你碰到过最邪门的 Bug 是哪个？