一、事情的起因：一个“看起来没问题”的模块

公司有个主要订单模块，代码历史可以追溯到2019年。五年间前后端加起来换了12人注释里还留着初代架构师的 QQ 号。

这个模块有个特点：看起来一切正常。

• 线上从未出现过 P0 故障
• 测试用例通过率高达%98%
• 产品经理三年没提过需求变更

但老程序员都知道，“看起来正常”往往是最危险的信号。

I 接手时代码里充斥着这样的“艺术”：

// 不要删。删了会崩，原因未知
setTimeout => {
if {
// . 临时修复，待验证
fixSomething;}
},)，老实说，

不知道。谁加的，Git blame 显示是一个已注销账号。fixSomething 干了什么？注释写着“待验证”——已经等了三年。

二、我决定“考古”

周末花两天用 Chrome DevTools 的 Performance 面板 + 手动断点，还原了这个模块的“黑历史”： 第一层：定时器地狱 那个 setTimeout 为了解决 race condition。2020 年某个版本后端接口响应变慢，为兜底加了秒级延迟；接口好了后定时器被遗忘，却被后续代码依赖上去。

第二层：全局变量瘟疫 __magic_flag 是另一同事加的，用来标记“是否已经修复过”。但如果使用者快速切换页面flag 未重置，就会跳过修复逻辑。不过，

第三层：沉默的灾难 最可怕的是这个 bug 几乎不会触发。只有在网络抖动 + 使用者手速极快 + 特定浏览器版本叠加时才出现。过去五年线上大概出现了

User Pain Point：

• Tester 报告 “刷新即可”，却没有真正复现根本原因。
• User 在关键时刻因为瞬间错误被迫重试，却无视隐藏风险。

三、修复方案：不是打补丁，是拆雷

1️⃣ 用 Promise 链替代定时器

// 原来
// setTimeout => {
// if fixSomething;// },)，// 后来
await ensureOrderDataReady;// 明确的数据就绪信号，不再需要魔法数字
fixSomething;

2️⃣ 引入状态机管理页面生命周期

type OrderPageState = 'idle' | 'loading' | 'ready' | 'error';const = useState;// 全局变量 __magic_flag 被彻底移除。不过，// 页面切换时状态自动重置，不存在脏状态残留。

3️⃣ 补全单元测试

• 网络超时 @testing-library/react 模拟断网重连场景，并断言状态机保持稳定。其实，
• 快速切换 模拟使用者多次点击页面跳转。确保没有遗漏 flag 重置逻辑。
• 结构 返回非标准 JSON 时仍能 graceful degrade，不触发 crash。
• 性能监控 加入 console.time/console.timeEnd 确认渲染时间不受影响。

四、最荒诞的结果

I 提交 PR 后审查很顺利。Senior 看完 diff 问：“就重构了一下？没加新功能，” 我说：“修了几个隐藏 bug。” 他问：“有工单吗，其实，” 我说：“没有，是周末顺手看的。其实，” 他点头合并，两周后测试组的小妹妹跑来问：“哥。你那个订单模块用例能分享吗？我们想学习，老实说，” 她说领导把它列为常用方法，因为“从来没出过线上问题”。我掩嘴笑，没有把真相说出来。

五、程序员的 “修 bug ”

This story illustrates a common paradox in software engineering:

• A. 天天报错的模块容易被关注和维护，看起来更健康；
• B. 从未报错但深藏危机的模块可能累积巨额技术债；话说回来，

A 当你真正把后者拆掉时没有人会感谢你——他们根本不知道原来有问题。而测试组以为这个模块“一直没问题”，领导认为你只是调整结构。而我自己如果不翻阅 Git 历史，也会以为它天生干净整洁。说起来，

六、唯一证据

The only clue lies in Git history:

refactor: 移除魔法定时器与全局状态标记
- 用 Promise 替代 setTimeout 轮询
- 引入 OrderPageState 状态机
- 补充边界条件测试例
- 移除 __magic_flag
BREAKING CHANGE: 无。但行为保持一致

I also kept a personal “考古笔记”，记录 __magic_flag 的前世今生和每一次改动细节。

七、写在最终