函数嵌套超3层应拆分为独立函数，避免维护灾难；递归过深需用栈模拟替代；多层字典应改用dataclass或namedtuple建模。
函数嵌套超过 3 层就该拆了
Python 里 def 套 def、循环里再写 lambda、with 块里又开 try/except，不是语法错，是维护灾难。缩进深了，眼一花就漏掉一层 return，或者误把内层变量当成外层作用域的。
- 真实场景：解析嵌套 JSON 后做校验，再拼 SQL 插入，最后发通知——4 层缩进起步，改个字段类型得扒三层才能定位到赋值点
- 判断信号：
Ctrl + [在编辑器里按一下没反应，说明至少 4 层缩进；或 PyCharm 提示 “Function is too complex” - 重构动作不是“重写”，而是把每层独立成
def，参数显式传入，返回明确值。别依赖闭包捕获变量，尤其涉及for循环里的i - 性能影响几乎为零：CPython 对短函数调用优化很好，反倒是深层嵌套让
dis.dis()看起来像天书，调试器 step-in 步步惊心
类方法里藏逻辑链不如拆成纯函数
看到 class DataProcessor: 里有个 process() 方法，里面先 self._clean()，再 self._enrich()，最后 self._export()，但三个私有方法只被调一次、不共享状态——这本质是披着类皮的流程脚本。
- 常见错误现象：单元测试难写，因为要 mock 整个实例；想复用
_enrich()到另一个项目，结果发现它偷偷读了self.config里的未文档化字段 - 正确做法：把每个步骤抽成独立函数，比如
clean_data()、enrich_data()，输入输出都是明确类型（dict或pd.DataFrame），不碰self - 参数差异关键点：原方法可能用
**kwargs掩盖参数膨胀，拆完后强制你面对真实依赖——比如enrich_data(data, api_client, timeout=30)比self._enrich()更易测、更易换 stub - 兼容性注意：如果已有代码强依赖
self状态（比如缓存中间结果），先加@property封装，别直接删属性
递归过深时优先考虑栈模拟，不是加 sys.setrecursionlimit()
RecursionError: maximum recursion depth exceeded 不是让你调高限制，是代码在喊“我撑不住了”。Python 默认递归深度约 1000，但真实业务里遍历嵌套字典+列表混合结构，20 层就爆了。
- 典型场景：解析无限层级的树形配置（如前端传来的菜单结构）、AST 遍历自定义 DSL
- 错误操作：
sys.setrecursionlimit(10000)—— 内存爆得更快，且上线后可能因不同机器栈大小不一致而偶发崩溃 - 实操建议：用
list当栈，while替代递归。例如遍历嵌套dict，把待处理的键值对塞进stack = [(root, path)]，每次pop()一个，遇到dict就把子项推入 - 性能对比：栈模拟通常快 20%–30%，因为免去函数调用开销；且能随时
break或记录当前路径，调试友好得多
用 typing.NamedTuple 或 dataclasses 替代多层字典嵌套
当你的代码里频繁出现 data['user']['profile']['address']['city']，还配着一堆 if 'user' in data and 'profile' in data['user']...，这不是 Python，这是字典俄罗斯方块。
立即学习“Python免费学习笔记（深入）”；
- 问题根源：嵌套
dict缺乏结构契约，IDE 补全失效，mypy 无法检查，运行时才报KeyError - 推荐选择：
dataclasses（Python 3.7+）比NamedTuple更灵活（支持默认值、可变、类型注解更自然），但若纯作不可变容器，NamedTuple内存更省、创建更快 - 关键动作：定义清晰边界。比如不要整个 API 响应套一个
DataClass，而是分层建模：User包含profile: Profile，Profile包含address: Address。这样user.profile.address.city既安全又可补全 - 坑点提醒：别在
dataclass里放可变默认值（如field(default=[])），也别让__post_init__做重 IO——它会在实例化时同步执行
最常被忽略的是“拆分时机”：不是等报了三次 KeyError 才动手，而是只要发现同一段嵌套访问出现在两个以上函数里，立刻建模型。否则下次加字段，你得 grep 十几个文件。
