try-except进入开销极小，真正昂贵的是异常抛出与栈展开；应避免用作控制流，仅用于低频错误兜底，捕获具体异常类型，善用else分离正常逻辑，复杂场景可用suppress。
try-except 本身不慢，但异常抛出很贵
很多人以为只要写了 try 就拖慢程序，其实不是。Python 解释器对 try 块的进入几乎零开销；真正昂贵的是触发 raise 和栈展开（stack unwinding）——尤其是当异常没被立即捕获、要逐层向上找 except 时。
这意味着：用 try-except 做「控制流」（比如反复尝试解析字符串）是危险的；而用它做「错误兜底」（比如打开文件失败后 fallback 到默认配置），只要异常极少发生，性能影响可忽略。
- 避免在循环内靠
int()+ValueError判断字符串是否为数字——改用str.isdigit()或正则预检 - 若必须解析，优先用
str.isdecimal()这类无异常方法快速排除，再进try - 不要为了“简洁”把多个可能出错的操作塞进同一个
try块，否则一次异常会掩盖其他位置的问题，也增加排查成本
捕获具体异常类型，别用裸 except:
写 except: 或 except Exception: 看似省事，实则埋雷：它会吞掉 KeyboardInterrupt、SystemExit，甚至你手动 raise 的调试用异常，导致程序无法响应 Ctrl+C 或提前退出。
更糟的是，它让性能分析失真——某些本该快速失败的逻辑（如 AttributeError）被泛化捕获后，可能掩盖了设计缺陷，后续被迫加更多兜底，形成恶性循环。
立即学习“Python免费学习笔记（深入）”；
- 只捕获你明确知道如何处理的异常，例如
FileNotFoundError、json.JSONDecodeError - 需要同时处理多种异常？用元组：
except (KeyError, IndexError): - 不确定时宁可让程序崩溃，也别用
except Exception as e:加日志后静默吞掉——这会让 bug 在生产环境潜伏更久
用 else 子句分离正常路径与异常路径
else 块只在 try 中没抛异常时执行，它不是语法糖，而是明确划分关注点的信号：这里不是错误处理逻辑，是主业务流程的延续。这对性能虽无直接提升，但能减少嵌套、避免误将正常代码写进 except 或重复执行。
常见误写是把本该放 else 的代码塞进 try，结果每次都要走异常检查路径（虽然不抛异常，但解释器仍需维护异常帧）；或者塞进 except 导致逻辑错乱。
- 文件读取成功后解析 JSON，应写成：
try: data = f.read() except FileNotFoundError: data = DEFAULT_CONFIG else: config = json.loads(data) # 只在读取成功后解析 - 避免：
try: data = f.read(); config = json.loads(data)—— 这样json.loads()的异常也会被同一个except捕获，类型混淆
复杂场景下考虑 contextlib.suppress 或自定义上下文管理器
当某段代码「预期会失败，且失败完全可忽略」（比如删除临时文件、关闭已关闭的 socket），用 try-except-pass 显得啰嗦又难读。这时 contextlib.suppress 更精准：
from contextlib import suppress
<p>with suppress(FileNotFoundError):
os.remove('/tmp/outdated.cache')它底层仍是 try-except，但语义清晰、无额外变量污染，且比手写更少出错。若逻辑稍复杂（如需记录忽略次数、按条件决定是否忽略），就该自己写上下文管理器，而不是堆砌嵌套 try。
注意：suppress 不处理异常传播，也不支持 else 或 finally，别试图用它替代完整错误处理流程。
最常被忽略的是异常发生的上下文深度——哪怕只多一层函数调用，栈展开成本就明显上升。所以，把可能出错的操作尽量靠近顶层捕获，而不是层层 try 嵌套。
