安全重构与回归保证

重构的价值是改善结构而不改变行为，但它也是最容易"悄悄改坏"的操作。安全重构的核心是先有行为基线、与功能变更分离、小步提交、随时可回退。本节给出安全重构前提、标准步骤、必须避免的混合改动方式，以及回归保证与回退手段。

一、安全重构的五个前提

1. 行为保持不变：重构目标只调整内部结构、可读性与组织方式，用户可见行为与对外契约不改变。
2. 先有回归基线：重构前先跑通可用测试或建立手工复现记录，使"行为是否变化"有客观对照。
3. 工作区干净：开始前用 git status 确认无未提交的混杂改动，避免把重构与既有修改混在一起。
4. 小步推进：一次只做一类结构变换（提取、重命名、搬移、拆并），每步验证后再下一步。
5. 随时可回退：以版本控制为安全网，每步形成可单独回退的提交节点。

二、安全重构标准步骤

步骤	做法	验证/产出
1. 明确重构目标	只选定一种结构问题（重复、过长、职责混杂等），不夹带功能调整	写明改什么、不改什么、保持不变的行为
2. 建立基线	运行现有测试/构建或记录关键行为输出	一份重构前可复现的基线结果
3. 小步变换	按依赖方向逐处调整，每处聚焦单一结构目的	每步可独立编译/运行
4. 即时回归	每完成一类变换即对照基线跑验证，发现行为漂移立即停手	无新增失败、关键行为一致
5. 提交固化	验证通过后人工提交，形成清晰、可单独回退的节点	结构变更与功能变更不混在同一提交
6. 复查差异	用 git diff 确认改动均属结构性质，无逻辑被顺手改写	diff 与重构目标一致

三、必须避免的混合改动

高风险做法	为什么危险	安全替代
重构同时修 Bug、加功能	行为一旦变化无法区分是结构副作用还是有意改动	先提交稳定版本，再分别做功能/缺陷修复与重构
无测试兜底直接大改结构	缺少基线，结构改变后问题难以察觉	先补特征测试或关键路径回归基线，再动手
跨层、跨模块一次性搬移	影响面过大、diff 难以审查、回退成本高	按模块局部重构，逐块验证合并
删除"看起来无用"的代码	可能被反射、配置、测试或入口间接引用	先确认无引用与无动态调用，再单独删除并保留回退点
重构中改动命名风格与签名	同时改结构和契约，扩大兼容风险	契约调整作为独立变更，先稳定兼容策略
凭"更优雅"一次性重写	脱离现状的重写等同于重实现，缺陷率高	渐进改善，每步行为可证不变

四、回归保证与回退策略

• 测试优先覆盖核心路径：关键逻辑应在重构前具备可重复执行的测试或脚本验证入口。
• 基线与结果对照：重构前后运行同一组检查，比对通过情况与关键输出，而不是只看代码是否"更整齐"。
• 发现漂移立即停止：行为结果出现差异时先定位是实现疏漏还是基线缺失，不以继续重写掩盖问题。
• 干净回退：未提交的不当改动用 git restore 还原；已提交但有问题的变更，通过版本历史回退到上一可用节点，再重新规划。
• 提交信息区分目的：结构变更与功能变更分别提交、分别描述，保证历史可解释、可单独回滚。

五、FAQ

问题	处理建议
项目测试很少怎么做重构	先围绕要重构的核心路径补最小回归验证，或用脚本固化当前输出，降低无保护重构风险。
重构过程中想顺手修个小 Bug	忍住并另立任务；同一提交混合后将无法干净归因与回退。
如何判断重构是否"改坏了"	以重构前基线对照测试与关键行为；任何非预期的失败或行为变化都视为漂移。
大型遗留代码是否适合大重构	优先局部、渐进、围绕新需求的小重构；避免脱离价值驱动的大规模重写。

六、动手练习

• 练习：选一处重复或过长的现有代码，先跑通并记录当前验证结果，按"单一结构变换+小步提交+回归对照"完成一次重构，最后用 git diff 自检确认无逻辑被顺手改变。