Python 异常处理对性能的影响

try-except在正常流程下几乎无开销，仅异常抛出时因栈展开和回溯构建显著变慢；应捕获具体异常类型，避免用except exception:掩盖错误；raise e会丢失原始traceback，应优先用raise或raise newerror(…) from e。

try-except 在热点路径里到底慢不慢

慢，但只在真的抛出异常时才明显拖慢。正常流程下 try 块本身几乎没开销——Cpython 3.11+ 甚至把空 try 编译成和普通代码一样快的字节码。

真正卡住的是异常被触发、栈展开、回溯对象构建这一整套动作。一次 ValueError 抛出可能比同逻辑的 if 判断慢 10–100 倍，取决于嵌套深度和异常信息长度。

• 别在循环体里靠 int() + except ValueError 解析大量字符串；改用 str.isdigit() 或正则预筛
• Web 请求中解析 json 失败是典型异常场景，但只发生在少数坏请求上，这时用 try/except 合理；若你主动构造数据并反复 try，就是设计问题
• try/finally 没异常时开销极低，适合资源清理，不用犹豫

为什么 except Exception: 比 except ValueError: 更贵

不是语法层面更贵，而是匹配逻辑导致更多工作：Python 要逐层检查异常类的继承链，Exception 是顶层基类，所有异常都匹配它，但解释器仍得走完 MRO 查找——这点开销微乎其微；真正代价来自「掩盖真实错误」引发的后续调试成本。

比如本该捕获 KeyError 却写了 except Exception，结果把 KeyboardInterrupt 或 MemoryError 也吞了，程序卡死或静默失败，排查时反而花掉几十倍时间。

立即学习“Python免费学习笔记（深入）”；

• 永远优先捕获具体异常类型：except ValueError:、except FileNotFoundError:
• 需要兜底时，用 except (ValueError, TypeError): 明确列出，别偷懒写 except Exception:
• except BaseException: 几乎不该出现——它连 SystemExit 和 KeyboardInterrupt 都拦，会破坏 Ctrl+C

raise 和 raise e 的性能与行为差异

raise（无参数）原样重抛当前异常，保留原始 traceback；raise e 会创建新 traceback，从当前行开始，丢失原始出错位置。性能上后者略重，但差别远小于异常本身的构造开销。

真正影响大的是语义：用 raise e 就等于主动丢掉调用栈，让定位变困难。很多日志里看到 “line 42 in foo” 却找不到上游，就是这里被截断了。

• 想加日志再抛？用 logger.exception("xxx") + raise（不带参数）
• 必须改异常类型时，用 raise NewError(...) from e，保留因果链
• 绝对避免 raise e，除非你明确知道且接受栈丢失

async def 里 try-except 的特殊注意点

协程函数里异常传播和同步代码一致，但 await 点可能跨事件循环迭代，导致 traceback 中混入 await 行和实际出错行。这不是性能问题，而是可读性陷阱——你看到的报错位置未必是源头。

更隐蔽的问题是：某些异步库（如早期 aiohttp）在连接超时等场景下抛出的异常类型不稳定，except asyncio.TimeoutError 可能抓不到，得查文档确认实际抛什么。

• 用 asyncio.wait_for(..., timeout=) 时，超时一定抛 asyncio.TimeoutError，放心捕获
• 用 loop.run_in_executor 调用同步阻塞函数时，异常仍在 executor 线程抛出，但会被包装进 concurrent.futures.CancelledError 或原异常，需对应处理
• 别在 __aexit__ 里裸写 raise，可能干扰异步上下文管理器的异常传播协议

异常处理的性能损耗从来不在语法上，而在你是否把它当成了控制流替代品。最常被忽略的，是异常发生后那几毫秒之外的代价：日志膨胀、监控误报、协作同学多花二十分钟定位一个本可静态发现的类型错误。