重构前必须补全测试用例，以通过测试而非人眼比对保障行为一致；需覆盖正常路径、异常分支、副作用三类场景，并验证签名、文档示例、类型提示及隐式行为差异。
重构前必须补全的测试用例
行为一致最直接的保障不是靠人眼比对，而是靠测试能跑过。很多重构失败，是因为原有逻辑藏在边界条件里，而你没测到。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 先运行现有测试，确认它们全部通过；如果已有测试覆盖率低，优先补
pytest用例，覆盖输入为None、空字符串、负数、极大值等典型边界 - 对被重构函数，至少写三类用例：正常路径、异常分支（比如抛
ValueError的情况）、副作用（如是否修改了传入的list或dict） - 别依赖「它以前没出过问题」——Python 的隐式类型转换、
==和is混用、可变默认参数都可能让旧代码「碰巧」工作
用 diff + 手动执行验证关键路径
测试能防错，但不能代替对逻辑流的确认。尤其当重构涉及控制流调整（比如把嵌套 if 拆成卫语句，或把循环改成 map），容易漏掉短路逻辑或提前退出。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 重构后，用
git diff对比前后，重点看条件判断、return、raise、break出现的位置和顺序是否等价 - 挑 2–3 个典型输入（比如一个成功 case、一个失败 case、一个空输入），在 Python REPL 里手动调用新旧函数，对比返回值、异常类型、以及是否修改了外部变量
- 注意
dict.keys()返回视图对象，list(dict.keys())和sorted(dict.keys())行为不同；类似地，range(5)和[0,1,2,3,4]在某些上下文中不等价
警惕 Python 特有的隐式行为差异
有些重构看似只是语法糖替换，却会改变实际行为，尤其是涉及对象身份、迭代协议和求值时机时。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 把
for i in range(len(lst)):改成for item in lst:是安全的，但换成enumerate(lst)后，如果原逻辑依赖索引越界报错，就可能掩盖问题 - 用生成器表达式替代列表推导式（如
(x*2 for x in data)替代[x*2 for x in data]）会延迟求值，如果后续代码依赖「立刻计算并报错」，就会失效 -
data.pop(0)和data[0]; del data[0]看似等价，但前者是原子操作，后者在多线程下可能引发IndexError或读到脏数据
重构后要检查的三类兼容性
行为一致不只是函数输出一样，还包括调用方无需改代码就能继续用。很多人只测函数本身，忘了它处在什么上下文中。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 检查函数签名：参数名、默认值、
*args/**kwargs是否保留；改def func(a, b=1)为def func(*, a, b=1)会破坏位置调用 - 检查文档字符串里的示例代码是否仍可直接复制粘贴运行；很多项目靠 doctest 验证，改完不跑
python -m doctest就等于没验 - 检查类型提示：如果加了
-> List[str]，但实际返回的是tuple或生成器，静态检查（如mypy）会放过，但运行时可能崩在下游的.append()上
最难盯住的是那些「没报错也没改结果，但改了执行顺序或对象生命周期」的地方——比如把闭包里捕获的变量从引用改为拷贝，或者把 datetime.now() 提前到函数外。这些不会让单元测试失败，却可能在真实请求链路中暴露竞态或时间漂移。
