Python的try except语句是保证程序健壮性的核心手段，但不少人对它的性能代价存在误解：有人认为只要写了try就必然拖慢速度，也有人把异常当成流程控制随意使用，结果程序慢得离谱。事实上，try except的性能开销主要发生在异常真正被抛出的那一刻，而不是try语句本身。理解这一点，是写出高性能且健壮的Python代码的前提。
try except的性能开销到底在哪里
在CPython中，当代码进入try语句块时，解释器只是把当前的异常处理器信息压入一个内部栈，这个过程几乎没有额外计算，开销接近于零。可以用一个简单的实验验证：把一段纯计算代码分别放在try块内外，用timeit测量耗时，两者几乎没有差别。
import timeit
code_plain = "x = 1 + 1"
code_in_try = """
try:
x = 1 + 1
except Exception:
pass
"""
print(timeit.timeit(code_plain, number=1000000))
print(timeit.timeit(code_in_try, number=1000000))
# 两者耗时非常接近，差异在噪声范围内
真正昂贵的是异常被抛出的过程。当raise执行时，解释器要做几件事：实例化异常对象、捕获当前调用堆栈并构建traceback、沿着调用栈逐层查找匹配的except处理器、逐帧解栈。其中构建traceback尤其昂贵，因为每上一级调用栈都要记录源码位置信息。此外，Python 3默认开启异常链（implicit chaining），异常对象会保存__context__、__cause__等引用，进一步增加了对象构建成本。
下面这个对比可以直观看出抛异常的代价：
import timeit
# 不抛异常，用返回值表示失败
dict_get = "d.get(1)"
# 抛出KeyError再捕获
dict_try = """
try:
d[1]
except KeyError:
pass
"""
setup = "d = {}"
print("get方式:", timeit.timeit(dict_get, setup, number=1000000))
print("异常方式:", timeit.timeit(dict_try, setup, number=1000000))
# 异常方式通常慢一个数量级以上
结论很明确：try块本身免费，异常触发昂贵。优化方向自然就是两个——减少异常发生的频率，以及降低单次异常的处理成本。
EAFP与LBYL：两种风格的性能权衡
Python社区有两种典型的错误处理风格。EAFP（Easier to Ask Forgiveness than Permission）指先直接执行操作，出错了再捕获，这是Python推崇的惯用法；LBYL（Look Before You Leap）指执行前先检查条件，比如用in判断键是否存在。从性能角度看，哪种更好取决于失败率。
当操作大概率会成功时，EAFP几乎是免费的，因为它省去了每次都执行的检查逻辑，而且检查本身也可能存在竞态条件。比如并发环境下，先判断key存在再取值，两步之间key可能已被删除，而直接get再处理异常则是原子性的。但当失败率很高时，EAFP会反复触发昂贵的异常构建流程，性能急剧下降。
一个常见的反面教材是在循环中用异常处理跳过不存在的键：
# 差：循环中大量KeyError被抛出
result = []
for k in keys:
try:
result.append(data[k])
except KeyError:
continue
# 好：用get方法避免异常触发
result = [v for k in keys if (v := data.get(k)) is not None]
经验法则是：成功路径占绝对多数时用EAFP，失败是常态或需要频繁跳过时改用显式检查或get、setdefault这类带默认值的方法。dict的get方法、getattr的default参数、re模块的match返回None，这些接口设计本身就是为了让你避免触发异常。
五个实用的异常处理优化技巧
第一，缩小try块的范围。很多人习惯把一大段逻辑整个包进try，这会带来两个问题：一是意外捕获了不该捕获的异常，掩盖真实bug；二是排查问题时定位困难。精确的写法是只包裹可能出错的那一行，并在except中指明具体异常类型，坚决避免裸的except:，它会连KeyboardInterrupt、SystemExit一起吞掉。
第二，不要用异常做常规流程控制。循环遍历迭代器时，StopIteration由for语句内部处理是高效的，但如果你自己写while循环手动catch StopIteration来退出，每次迭代结束都要付出一次异常构建的成本。Python 3.7以后，生成器函数内部抛出StopIteration甚至会被转成RuntimeError，就是为了防止这种滥用。
第三，合理利用异常对象复用。在极高性能敏感的场景下，可以预先创建异常实例，抛出时直接raise这个实例，省去每次实例化的开销。不过要注意，异常实例被raise多次时traceback会被覆盖，这种优化只适合性能极致追求且不依赖traceback的场景。
class FastFail(Exception):
pass
# 预先构建异常实例，多次raise时省去实例化开销
_cached_exc = FastFail("预定义错误")
def check(value):
if value < 0:
raise _cached_exc
第四，善用else和finally子句。try的else块只在未发生异常时执行，把后续逻辑放在else里，可以避免意外捕获本不属于try范围的异常，这既是正确性问题，也间接避免了多余的异常处理路径。finally则适合做资源清理，配合with语句使用上下文管理器，比手动try finally更简洁也更不易出错。
第五，定位性能瓶颈时关注异常创建的堆栈深度。异常对象构建时会记录完整调用栈，调用层级越深，成本越高。如果某个深层递归或长调用链上频繁抛异常，可以考虑在底层先做条件判断，把异常拦在堆栈变深之前，或者用sys.setrecursionlimit配合重构降低栈深度。此外，在纯热循环里可以用if key in data做一次预检，把高频小概率失败转换成一次廉价的字典查找。
总的来说，try except不是性能黑洞，被滥用的异常才是。写代码时先问自己：这个异常是意外情况还是常态分支？答案是前者，放心用try；答案是后者，换成条件判断或带默认值的接口。用timeit实测关键路径，比任何经验法则都可靠。
Python异常处理try except性能异常捕获优化修改时间：2026-09-04 00:03:05