Python 循环中 try/except 的性能成本

try/except在无异常时几乎零开销，但异常触发时因构建traceback等操作而慢10–100倍；高频循环中错误常见时应优先LBYL预检，异常率低于1%可用EAFP。

在 Python 循环中频繁使用 try/except 并不一定会显著拖慢程序，但它的实际开销取决于“异常是否发生”——异常未触发时，try/except 几乎无成本；一旦抛出并捕获异常，开销会明显上升。

正常执行时 try/except 几乎零开销

Python 在编译阶段就为 try 块生成了额外的字节码（如 SETUP_EXCEPT），但只要没发生异常，解释器不会进入异常处理路径。这意味着：

• 单纯写 try: ... except: ... 不影响循环主体的执行速度
• 与不加 try 的纯逻辑相比，性能差异通常在纳秒级，可忽略
• CPython 的优化已让“无异常的 try”接近空操作

异常触发时成本陡增

每次异常被抛出并捕获，Python 需要：

• 构建完整的 traceback 对象（包含文件名、行号、局部变量快照等）
• 逐层回溯调用栈，查找匹配的 except 块
• 清空当前帧、切换控制流、初始化异常处理上下文

这个过程比普通函数调用或条件判断慢 10–100 倍以上。例如，在循环中对每个字符串调用 int(s) 并靠 ValueError 捕获非法输入，比预先用 s.isdigit() 或正则过滤慢得多。

更高效的做法：EAFP vs LBYL 的权衡

Python 推崇 EAFP（“请求宽恕比许可容易”），但前提是“异常是罕见事件”。若错误情况较常见（比如解析大量混合格式数据），应转为 LBYL（“先查看再行动”）：

• ✅ 推荐：用 str.isdigit()、hasattr()、in dict 等快速预检，再执行可能失败的操作
• ⚠️ 谨慎：在高频循环中把 try/except 当作控制流（如用 KeyError 驱动字典默认值逻辑）
• ? 折中：将 try/except 提到循环外（如批量解析后统一处理错误），或用 functools.singledispatch 分离类型分支

实测建议：别猜，用 timeit 验证

不同场景差异大，直接测量最可靠：

• 对典型数据运行 timeit.timeit(..., number=100000)
• 对比 try/except int() 和 if s.isdecimal(): int(s)
• 注意测试数据中异常比例（1% 错误 vs 50% 错误结果完全不同）

你会发现：异常率

低于 ~1%，try/except 更简洁且不慢；超过 ~10%，预检往往更快。