应使用分层捕获替代层层 try 套 try：外层捕获资源类异常（如 filenotfounderror），内层专注数据类异常（如 jsondecodeerror、keyerror）；将各操作封装为独立函数并转换为语义明确的业务异常；遵循 eafp 原则，避免预检 if + try 双重嵌套；禁用空 except 和 finally 中 return。
用分层捕获替代层层 try 套 try
深层嵌套往往源于把多个独立错误场景混在同一个 try 块里，比如同时处理文件打开、JSON 解析、字段提取。结果是 except 块职责混乱，一个 except 既要管路径不存在，又要管内容非法，还要管键缺失。
正确做法是按错误发生层级拆开：最外层捕获资源不可用类异常（FileNotFoundError、PermissionError），内层只管数据解析类异常（json.JSONDecodeError、KeyError）。
- 文件读取失败 → 外层
except FileNotFoundError，走降级或报错退出 - JSON 格式错误 → 内层
except json.JSONDecodeError，记录原始内容片段便于排查 - 字段缺失或类型错 → 再下一层或单独函数中捕获
KeyError/ValueError
把每个可能出错的操作封装成独立函数
把 read_file、parse_config、validate_user 各自的异常处理逻辑收进函数内部，外层调用时只面对明确语义的异常，比如 ConfigLoadError 或 InvalidUserError。
这样做的好处是：外层代码不用再写三层 try，也不用重复日志、重试、默认值逻辑；测试时可直接 mock 单个函数，而非模拟整个嵌套流程。
- 函数内捕获具体异常并转换为业务异常（如
raise ConfigLoadError("missing 'db_url'") from e） - 外层统一用
except ConfigLoadError处理配置加载失败，不关心底层是文件还是网络 - 避免在函数里
except后静默return None，否则调用方无法区分“没数据”和“出错了”
用 EAFP 原则消除 if + try 的双重嵌套
常见反模式是先用 os.path.exists() 判断，再 open()，再 json.load()，最后还套一层 try。这既冗余，又存在竞态——路径可能在判断后、打开前被删掉。
快速生成专业的 Python 脚本和应用代码。一键创建完整项目结构，支持CLI、API、爬虫、Bot、Django等多种项目类型，包含完整的项目结构、配置文件、依赖管理、测试、README和文档。
EAFP（Easier to Ask for Forgiveness than Permission）要求你跳过所有预检，直接做，靠异常兜底。它天然排斥前置 if 嵌套，也减少 try 层数。
- 删掉
if os.path.isfile(path):，直接try: open(path) ... except FileNotFoundError: - 删掉
if key in data:，直接data["key"]，用except KeyError:处理 -
with本身已确保资源清理，不需要额外try包裹它——with不是异常源，json.load()才是
警惕 finally 中 return 覆盖异常和空 except 吞掉关键信号
这两处不是嵌套问题本身，但常出现在试图“兜住一切”的深层结构里，让调试雪上加霜。
比如在嵌套最外层加了个 finally: return default_value，结果 ValueError 被彻底吃掉；或者用 except: 捕获所有异常，连 KeyboardInterrupt 都被拦下，导致 Ctrl+C 失效。
- 永远不要在
finally里写return或raise，除非你明确知道它会覆盖什么 -
except:和except Exception:必须禁用，只允许except (ValueError, TypeError):这种元组形式 - 如果真需要兜底，放在最外层入口函数（如
main()），且必须用logging.exception()记完整堆栈
嵌套本身不危险，危险的是每层都模糊责任边界——比如某层既想处理网络超时，又顺手 catch 了 KeyError，还偷偷吞掉 ConnectionResetError。这种代码跑得越久，越难定位真实故障点。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
