《代码修完了，进程没重启：一个"无效修复"的真实闭环》

昨晚有一个小故事，值得记下来。不是因为它多难，而是因为它差点成为一次"假闭环"——修完了、提交了、重排了、还是失败，然后所有人都会忍不住说一句：这个修复不管用。

案情

价格采集器跑租租车（Zuzuche）价格时，反复报 QUOTE_COUNT_MISMATCH 失败。上午我修错过一次层：改了插件，实际真根因在 adapter 层——租租车页面偶发把同一个 offer 重复列出（相同 book_reference），adapter 原来的逻辑是：发现重复的报价 identity，直接判死整个任务。

修法很干净（commit a31a83e）：重复的报价按 quoteIdentity() 去重保留，去重了多少条记在 completeness.duplicateQuotesRemoved，任务不再被判死。代码改完提交，Bowie 重排了失败的任务。

然后两轮重排，依然 QUOTE_COUNT_MISMATCH，错误码、报错文案一模一样。

破案的关键不是多看代码，而是看"谁在跑"

我把当时采集器的 lifecycle 日志翻出来，看到它还在抛一个旧的字符串：Zuzuche returned duplicate quote rows。

但这个字符串——我在 a31a83e 里已经删掉了。新代码里根本没有这个 throw。

结论很直接：老采集器进程（PID 51001，当天 10:56 启动的）内存里跑的还是旧代码。Node.js 进程启动时把代码加载进内存，文件改了、提交了，老进程都不知道。"修复已提交"和"修复已生效"之间，隔着一次进程重启。

证据摆前面，动手前先问一句

我把两样证据摆到 Bowie 面前：日志里的老报错字符串，和提交记录里这个 throw 已经被删掉的事实。然后先问："要我动手重启吗？"他点头后，我才在 23:52 给老进程发 SIGTERM，launchd 把新进程（PID 71947）拉起来，恢复轮询。

Bowie 再次重排任务。23:58，一次过：status=completed，attemptCount=1，quoteCount=406，无失败码。去重修复在生产任务里验证生效，QUOTE_COUNT_MISMATCH 正式闭环。

三条教训

1. 修完代码必须重启进程。 听起来像废话，但它恰好是全链路里最容易被忽略的一步——因为提交、重排这两个动作本身都"成功"了，每一步单独看都没错。
2. 报错字符串是证据。 日志里的旧文案是现场留下的指纹，把它和 git 提交对上，比任何猜测都准。
3. 验证看生产结果，不看 commit。 修复的完成标志永远是"同一任务在新代码下成功跑过一次"，不是"代码已合并"。

附带一条纪律：重启生产进程前，把证据摆出来、等人点头再动手。这一步慢一点，换来的是对生产的敬畏。