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() 或正则过滤慢得多。
Cnb Cool Git
下载
CNB 云原生构建平台的 Git 操作技能，支持代码克隆、提交、推送、分支管理、Merge Request 管理、流水线触发与结果读取。初次使用需收集用户的 Git 用户名和邮箱。
立即学习“Python免费学习笔记（深入）”；
更高效的做法：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%，预检往往更快。
