try/except 在高成功率场景下比 if 更快，因其避免重复查找、省去冗余检查，且异常未触发时开销极小；但仅适用于失败率低、无副作用、逻辑清晰的 EAFP 场景。
在某些场景下，try/except 比 if 判断更快，核心原因不是异常处理本身快，而是 python 的字节码执行机制和“乐观执行”策略带来的开销差异——当正常路径占绝大多数（即“快乐路径”很常见），且检查逻辑本身较重时，跳过显式判断反而更高效。
字节码层面：if 要多做一次属性/键/类型检查
比如判断字典里是否存在某个键：
-
if 'key' in d: value = d['key']—— 实际执行两次查找：in检查一次哈希定位，d['key']再查一次； -
try: value = d['key']—— 只执行一次哈希查找，成功就直接用；失败才走异常流程（但异常是小概率事件）。
对内置容器（dict、list、getattr）这类底层用 C 实现、查找极快的操作，省掉一次重复查找的收益，在高频循环中会明显体现。
避免冗余类型/存在性检查
有些检查无法短路或天然昂贵。例如：
立即学习“Python免费学习笔记（深入）”；
- 检查对象是否有某属性并获取：
if hasattr(obj, 'attr'): x = obj.attr——hasattr内部其实已触发一次属性访问（还带异常捕获），再取一次，等于做了两轮尝试； - 直接
try: x = obj.attr—— 一次访问，成功即止；没属性才抛AttributeError。
类似地，解析 jsON 字段、读取配置项、调用可能缺失的方法等，都适用这一模式。
CPython 的异常处理开销被低估了
很多人以为 except 很重，其实只要异常不发生，try 块的进入成本几乎为零——它不分配栈帧、不预建异常对象、不触发 GC 扫描。只有 raise 那一刻才真正构建异常信息。因此，“高成功率 + 低失败率”的场景下，try/except 是典型的“用空间换时间”：把失败的代价延后、集中处理，而让主路径极致轻量。
但要注意边界：别滥用
这个优势有前提：
- 异常必须是真正的“例外”，失败率建议低于 ~1–5%；
- 被保护的代码不能有副作用（比如
try: f(); g()中f()失败时g()就不该执行）； - 不要用它替代逻辑清晰的条件分支（比如
if x is None这种廉价检查）； - 嵌套太深或跨函数传播异常，会削弱可读性和调试效率。
本质上，这是 Python 鼓励的 EAFP（Easier to Ask for Forgiveness than Permission）风格——和 LBYL（Look Before You Leap）相对，它更贴近动态语言的运行时特性，也更契合解释器的优化路径。