Python 异常处理与错误机制：try/except、异常链与性能代价

更新时间：2026-09-03。本文回答：try/except 到底有没有性能开销？为什么 Python 社区推崇 EAFP（先做了再说，错了再处理）而不是 LBYL（先检查再做）？raise A from B 里的 from 有什么用？traceback 那一串调用栈能不能在代码里拿到？finally 里 return 会发生什么？ 异常是 Python 的错误处理主线，用得好能让代码又短又健壮，用错（拿异常当正常控制流、吞异常、裸 except:）则是线上事故高发区。5 个 demo 全部在服务器（CentOS 7，4 核，Python 3.6.8，纯标准库）实测。

一、两种哲学：EAFP vs LBYL

处理「可能失败」的操作，有两种风格。Python 官方术语：

• LBYL（Look Before You Leap，跳之前先看）：先做条件检查，确认安全再执行。

  if key in d:          # 先看
      v = d[key]
  else:
      v = default

• EAFP（It's Easier to Ask Forgiveness than Permission，求原谅比求许可容易）：直接执行，失败了再 except。

  try:                  # 先做
      v = d[key]
  except KeyError:      # 错了再原谅
      v = default

Python 文化明显偏爱 EAFP，原因不只是风格，还有实打实的性能和正确性依据。demo1（d1_eafp_perf/eafp_perf.py）对「从字典取值、键可能不存在」这个最常见场景，按不同命中率实测：

== 键 100% 命中（几乎不抛异常）==
    LBYL (if k in d)        0.222 s
    EAFP (try: d[k] except) 0.157 s
    -> EAFP 相对 LBYL: 0.71x
== 键 90% 命中（10% 走 except）==
    LBYL                     0.214 s
    EAFP                     0.220 s   -> 1.03x（持平）
== 键 0% 命中（全走 except，最差情况）==
    LBYL                     0.094 s
    EAFP                     0.655 s   -> 6.97x（慢 7 倍）

读法非常关键：

• 命中（正常路径）时，EAFP 反而更快（0.71x）。因为 LBYL 的 if key in d 和随后的 d[key] 是两次字典查找（一次判断、一次取值），而 EAFP 的 d[key] 只有一次查找；try 块在不抛异常时几乎不花时间（下一节量化）。
• 一旦大量走 except，EAFP 急剧变慢（6.97x），因为抛异常很贵（建 traceback、回溯栈、展开，见第二节）。
• 注意 0% 命中时 LBYL 也变快到 0.094s（in 判断不存在也很快、且不取值）。

所以准则是：异常用于「真正异常、罕见」的情况就用 EAFP（正常路径快、代码简洁、还避免了检查与执行之间的竞态——if key in d 通过后另一个线程可能刚把它删了）；如果某个「失败」其实是高频正常分支（比如循环里大量键都可能没有），就该老老实实用 LBYL 或 d.get(key, default)。 这跟 01 · 性能优化路径 的「先测量」一致：别凭感觉，看命中率。

二、try 块几乎免费，raise 异常很贵

很多人（尤其从 C 来的）会条件反射地觉得「加 try 会拖慢代码」，于是把正常逻辑包得干干净净、异常处理到处藏。这个直觉在 Python 里一半是错的。demo2（d2_raise_cost/raise_cost.py）把成本拆成两档实测：

    普通调用 (baseline)              0.153 s
    try 块但不抛异常                 0.156 s
    raise + 同函数 except 抓住       0.463 s
    raise 跨一层栈再被抓住           0.614 s

    try 不抛 / 基线   = 1.02x（进入 try 块几乎免费）
    raise+catch / 基线 = 3.02x
    跨栈 raise / 基线  = 4.02x

结论很清楚：

• 「挂着 try/except」几乎零成本（1.02x）。CPython 编译时，try 块对应 SETUP_EXCEPT 这类指令，它只是把「出异常时跳到哪」记到一个栈上，正常往下执行时没有任何额外动作——就像在函数里登记了一个「逃生通道」，不用就不花钱。这和 C++ 的「零成本异常」（concepts/elf/eh-frame：正常路径一条指令都不加，代价全在 .eh_frame 展开表和异常发生时）思想一致。
• 真正贵的是「抛」这个动作（3~4x 起）。抛异常时 CPython 要：① 实例化异常对象；② 从当前帧开始回溯整条调用栈，为每一帧构建 traceback 对象（记录文件名、行号、函数名）；③ 沿栈向上逐帧展开，直到找到能匹配的 except。浅栈实测 3~4x，栈越深越慢；如果还打印/格式化 traceback，开销可达数十倍。

这就解释了第一节为什么「高频失败」时 EAFP 崩到 6.97x：每次失败都在付「建 traceback + 栈展开」的钱。由此得到工程纪律：

try/except 当安全网尽管挂（正常路径不花钱）；但永远不要把抛异常当正常控制流。 典型反例：用 StopIteration 跳出循环（迭代器协议内部除外）、用 KeyError 当「键没有就用默认」的高频默认分支、递归里用异常返回结果。这些在失败频繁时会慢数倍。

三、异常是对象：层级与「精确捕获」

异常不是字符串/错误码，而是类的实例，有一棵继承树。所有内置异常都继承自 BaseException，但你日常该捕获的是它的子类 Exception：

BaseException
 ├── SystemExit        # sys.exit() 抛出
 ├── KeyboardInterrupt # Ctrl+C
 ├── GeneratorExit     # 生成器被关闭
 └── Exception         # 所有「业务/运行时」错误都在这下面
      ├── ValueError / TypeError / KeyError / IndexError
      ├── OSError (FileNotFoundError 等)
      ├── AttributeError / NameError
      └── ...（你自定义的异常也应继承 Exception）

三条铁律：

1. 捕获具体异常，不要裸 except:。 except: 会连 KeyboardInterrupt、SystemExit 一起吞掉——意味着 Ctrl+C 杀不掉程序、sys.exit() 退不出去。写 except ValueError: 或至少 except Exception as e:。
2. 从具体到宽泛排列。 多个 except 时，子类要写在父类前面，否则父类先匹配、子类永远到不了。
3. 自定义异常继承 Exception（或更具体的内置异常），不要继承 BaseException。 给业务错误建自己的异常类（如 class OrderError(Exception)），调用方就能按类型精确区分，而不是靠解析错误信息字符串。

class InsufficientBalanceError(Exception):
    """余额不足——业务异常，继承 Exception。"""
    def __init__(self, balance, amount):
        super().__init__("余额 %d，不足以支付 %d" % (balance, amount))
        self.balance, self.amount = balance, amount

def pay(balance, amount):
    if amount > balance:
        raise InsufficientBalanceError(balance, amount)   # 携带现场数据
    return balance - amount

异常类可以像上面这样携带结构化数据（e.balance、e.amount），这比返回 (-1, "余额不足") 之类的错误码元组强得多：错误不会被静默忽略（不捕获就沿栈报错），还能带上完整上下文。这是 Python 相对 Go「多返回值错误码」哲学（Go 错误处理）的不同取舍——Go 显式但容易漏写 if err != nil，Python 异常默认「不处理就炸」，更安全但要付栈展开成本。

四、异常链：__cause__、__context__ 与 raise from

真实系统里错误往往层层包装：底层「文件找不到」导致中层「配置加载失败」、最终表现为顶层「服务启动失败」。Python 3 用异常链把因果串起来，有两种来源，demo3（d3_chained_exc/chained_exc.py）实测区分：

• __cause__（显式链）：你主动写 raise NewError(...) from old_err，明确表达「我是因为 old_err 才抛新错」。traceback 会打印 The above exception was the direct cause of the following exception:。
• __context__（隐式链）：你在 except 块里处理异常 A 时，又抛了异常 B，Python 自动把 A 挂到 B 的 __context__。traceback 打印 During handling of the above exception, another exception occurred:。

# 显式：主动包装，保留根因
try:
    load_config()
except FileNotFoundError as e:
    raise RuntimeError("数据库初始化失败") from e      # e -> __cause__

# 隐式：处理 ValueError 时又出 ZeroDivisionError，自动挂 __context__
try:
    int("not-a-number")
except ValueError:
    return 1 / 0          # ZeroDivisionError.__context__ = ValueError

还有第三个开关 __suppress_context__：当你写 raise X from None 时置为 True，traceback 就不再打印底层那一段。这用于「底层原因是内部实现细节、不该暴露给用户」的场景——比如对外只说「请先运行 init 脚本」，而不把内部 FileNotFoundError 路径泄漏出去。demo3 实测三个属性：

① 显式链：RuntimeError  __cause__=FileNotFoundError(...)  __suppress_context__=True
② 隐式链：ZeroDivisionError  __context__=ValueError(...)  __cause__=None  suppress=False
③ from None：RuntimeError  __context__=FileNotFoundError  __suppress_context__=True（不打印链）

注意 from e 时 __suppress_context__ 也是 True——因为有了显式 __cause__，Python 就不再重复打印隐式的 __context__（虽然二者此时指向同一个对象）。

五、traceback 是一条可运行时遍历的帧链

异常对象的 __traceback__ 属性不是黑盒字符串，而是一个链表节点，每个节点对应一帧调用。demo4（d4_traceback_read/traceback_read.py）抓一个 ZeroDivisionError 后沿链遍历：

捕获到: ZeroDivisionError: integer division or modulo by zero
  帧#0  traceback_read.py:55  in <module>()
  帧#1  traceback_read.py:26  in handler()   局部变量: {'req': {'name': 'demo', 'base': 0}}
  帧#2  traceback_read.py:21  in service()   局部变量: {'base': 0, 'req': {...}}
  帧#3  traceback_read.py:15  in deep_calc() 局部变量: {'factor': 0, 'x': 0}

每个 traceback 节点的关键字段：

• tb_next：指向下一帧（调用者），到最外层为 None——串起来就是「从抛出点 <module> 到最深 deep_calc」的整条调用路径（注意顺序：tb_next 往外层走，最深帧在链表尾）。
• tb_frame：该帧的 frame 对象（和 05 · 字节码与求值循环 里 sys._getframe() 拿到的是同一种对象）。
  • tb_frame.f_code：代码对象，co_filename（文件）、co_name（函数名）、co_lineno 等。
  • tb_frame.f_locals：该帧所有局部变量的当前值字典——这就是「案发现场每个变量的值」。
• tb_lineno：这一帧里异常发生时执行到的行号。

意义在于：错误上报系统（Sentry、自建日志）就是沿这条链逐帧抓取 co_filename/tb_lineno/co_name/f_locals，序列化后上报——让你在线上看到「请求 base=0 一路传到 deep_calc 算出 factor=0 导致除零」的完整现场，而不是一句干巴巴的 division by zero。标准库 traceback 模块的 print_exc()、format_exception()、extract_tb() 也是对这条链的封装。

六、finally 一定跑、else 只在没异常时跑

try 语句完整形态是 try / except / else / finally 四段，各有明确职责，demo5（d5_finally_flow/finally_flow.py）实测了次序：

ok=True :  try -> else    -> finally
ok=False:  try -> except  -> finally

• finally：无论 try 块是正常结束、抛异常、还是 return/break/continue，都一定执行，且在异常向外传播、或 return 真正生效之前。它是释放资源（关文件、释放锁、关连接）的位置——这正是 01 · 上下文管理器与 with 的底层：with 就是把 try/finally 的清理逻辑收进 __exit__。

  [1] try 里 return：  finally 在 return 生效前跑
  [2] try 里抛异常：  finally 在异常冒泡到外层前跑

• else：仅当 try 块完全没抛异常才执行。把「成功后才做」的逻辑放 else，能让 try 块只包住「可能抛异常的那一句」，异常范围更精确，避免误伤：

  try:
      value = risky_parse(data)   # 只有这句可能抛
  except ValueError:
      handle()
  else:
      save(value)                 # 没出错才保存；放这里不会把 save 的异常误当 parse 的

最大的坑：不要在 finally 里 return/break。 demo5 实测：

[4] finally 里 return：
    try: raise ValueError("本该冒泡")
    finally: return "finally-return"
    -> 函数返回 finally-return，异常被静默丢弃！

finally 里一旦有 return/break，正在传播的异常会被悄悄吞掉，调用者完全不知道出过事——这是极难排查的 bug 来源。finally 只做清理，不做控制流转移。另外，若 finally 自己也抛异常，则新异常会替换掉旧异常（旧的进 __context__）。

七、常见场景速查表

场景	推荐写法	不推荐 / 坑
字典取可能不存在的键（命中为主）	try: d[k] except KeyError（EAFP，快）或 d.get(k, 默认)	高频缺失还硬用 try，慢 7 倍
先检查再做存在竞态（多线程/文件）	EAFP：直接做、失败再处理	if exists then open（检查后可能被删/改）
可能失败且失败是高频正常分支	LBYL：先 if 判断，或返回默认值	用异常当正常返回/跳出循环
包一层底层错误，对外报业务错误	raise BizError(...) from e	裸 raise BizError() 丢了根因
对外隐藏内部实现细节	raise BizError(...) from None	把内部路径/SQL 直接暴露给用户
关文件/锁/连接	with（= try/finally）或 finally	手动 close，漏写就泄漏
成功后才执行的逻辑	放 else 子句	全堆 try 里，异常范围过大
抓异常	except 具体异常 as e / except Exception	裸 except:（连 Ctrl+C 都吞）
记录现场再抛出	except ... as e: log(...); raise（裸 raise 保留栈）	raise e（截断 traceback）
线上错误现场	遍历 e.__traceback__ 取 f_locals	只记一句 str(e)，丢了变量现场

八、常见坑

#	坑	后果	正确做法
1	拿抛异常当高频正常控制流	每次失败付建 traceback+栈展开，缺失全中时慢 6.97x	高频分支用 LBYL/.get()/返回默认值
2	裸 except: 或 except BaseException	吞掉 KeyboardInterrupt/SystemExit，Ctrl+C 无效、退不出	except Exception as e 或具体异常
3	finally 里 return/break	静默吞掉正在传播的异常，调用者毫不知情	finally 只做清理，不做控制流
4	except ... as e: ...; raise e	重新抛出时截断 traceback，丢失原始调用栈	用裸 raise（原样继续传播）
5	捕获后只 pass 什么都不做	错误被悄悄吃掉，数据错了都不知道	至少记日志；真要忽略也写注释说明为何安全
6	多个 except 把父类放前面	子类分支永远不可达（被父类先匹配）	从具体（子类）到宽泛（父类）排列
7	自定义异常继承 BaseException	except Exception 抓不到，行为像系统退出信号	业务异常继承 Exception
8	包装底层错误不用 from	丢根因，排查时看不到真正起因；或默认连带链暴露内部细节	保留根因用 from e，对外隐藏用 from None
9	try 块包太大（整个函数体）	else/成功逻辑里的异常也被当成预期异常误捕	try 只包可能抛的那一句，成功逻辑放 else

九、代码位置与动手实验

所有 demo 均为纯标准库，Python 3.6+ 可直接跑，已在服务器（CentOS 7，4 核，Python 3.6.8）实测通过：

Demo	路径	演示
d1	demos/python-inter/exception/d1_eafp_perf/eafp_perf.py	EAFP vs LBYL 在 100%/90%/0% 命中率下耗时（0.71x / 1.03x / 6.97x）
d2	demos/python-inter/exception/d2_raise_cost/raise_cost.py	try 不抛 1.02x、raise 同函数抓 3.02x、跨栈 4.02x
d3	demos/python-inter/exception/d3_chained_exc/chained_exc.py	__cause__/__context__/from None 三种链与 traceback 文案
d4	demos/python-inter/exception/d4_traceback_read/traceback_read.py	遍历 __traceback__ 帧链，打印每帧函数/行号/局部变量
d5	demos/python-inter/exception/d5_finally_flow/finally_flow.py	finally 必跑、else 仅成功跑、finally return 吞异常
运行	demos/python-inter/exception/run_all.sh	一键跑全部 5 个

建议的延伸实验：① 把 d1 的容器换成 collections.defaultdict 或用 .get()，和两种写法对比；② 在 d2 里加深递归层数（比如 10 层调用再抛），看 3~4x 怎么随栈深涨上去；③ 给 d4 的异常用 traceback.format_exception(type(e), e, e.__traceback__) 打印，对照手工遍历结果；④ 故意写一个 finally: break 放进循环，观察循环里的异常如何被吞。

总结

• EAFP vs LBYL：正常（命中）路径 EAFP 更快（少一次哈希查找，实测 0.71x）、还无检查-执行竞态；但失败越频繁越慢（全失败 6.97x）。异常只该用于「真正罕见」的路径。
• try 免费、raise 昂贵：挂着 try/except 几乎零成本（1.02x，类似 C++ 零成本异常）；抛异常要建对象、回溯栈建 traceback、逐帧展开（浅栈 3~4x，深栈/打印更慢）。别用异常当控制流。
• 异常是对象：继承 Exception、捕获要精确（别裸 except:）、子类 except 放前面、可携带结构化现场数据。
• 异常链：raise New from old 设 __cause__（显式、保留根因）；处理中又抛自动挂 __context__（隐式）；from None 抑制链、隐藏内部细节。
• traceback 是帧链：__traceback__ → tb_next/tb_frame，f_locals 就是案发现场变量，错误上报靠它；traceback 模块是其封装。
• finally/else：finally 无论如何都跑（清理/资源，with 的底层），else 只在无异常时跑（放成功逻辑、缩小 try 范围）；finally 里绝不 return/break。

异常处理和 01 · 上下文管理器（with/try-finally 资源纪律）、00 · 生成器与装饰器（GeneratorExit）、05 · 字节码与求值循环（SETUP_EXCEPT、帧对象）一脉相承；想看 C 层「零成本异常」如何靠 .eh_frame 表实现，见 concepts/elf/eh-frame。