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，可能干扰异步上下文管理器的异常传播协议
