重构安全切换：让新旧代码用同一批输入对账

重构改动太大，代码审查很难单靠 diff 判断行为是否保持一致。dev.to 一篇文章提出：在一个明确的函数边界保留新旧实现，让它们用同一批冻结输入分别运行，比较输出，再切换默认路径。作者给出了迁移步骤，但示例代码和输出并非实测结果。

目前能确认什么

这套方法先缩小范围。作者选择有明确输入、输出的函数边界，而不是整个业务模块：采集真实调用输入，脱敏后保存为 JSONL，再手工补充空值、重复数据等边界样本。

新实现放在一个开关后，旧实现暂时保留。独立的对比程序直接运行两条路径，避免开关让其中一条始终没有执行机会。

比较前，需要集中处理输出中的不稳定字段，例如生成的 ID、键顺序和浮点精度。但删掉一个字段，就少验证一个字段。剩余差异必须逐项判定为预期变化或缺陷，并留下说明。

切换后，作者建议继续观察一个发布周期，再一起删除旧函数和开关。纯函数适合直接双跑；涉及写库、扣款等副作用时，需要先用桩隔离，不能直接重复执行。

我的判断

双跑最有用的地方，是给「行为保持不变」提供可检查的证据。

对前端程序员，价格计算、表单校验、数据转换这类输入输出明确的逻辑，可以借鉴这个思路。但旧实现只是对照基线，旧 bug 也可能被完整保留下来；主动修正行为时，需要另写预期断言。

证据的上限仍是样本覆盖。真实流量之外的罕见分支，要靠人工补齐；只优化延迟的重构，也无法靠输出一致证明收益。

节选没有给出实际项目的验证结果，示例差异不能当成成功率。文章还披露了 MonkeyCode 推广背景，其中 AI 的用途是生成候选输入。它能否补出有效边界，仍取决于人工筛选，不能据此判断其重构能力。