try/except 在循环内性能差因异常抛出开销大，应移至循环外或用 dict.get() 等防御式编程；空 except 会吞关键信号，须指定异常类型；异常链勿过度嵌套；自定义异常必须继承 Exception。
为什么 try/except 在循环里特别危险
频繁在循环内部用 try/except 捕获预期会发生的异常（比如字典键不存在、类型转换失败），会导致显著性能下降。CPython 中异常抛出本身开销就高，而每次 raise 都要构建 traceback 对象，哪怕你立刻捕获也绕不开这部分成本。
实操建议：
- 把
try/except移到循环外，或改用防御式编程：用dict.get(key, default)替代dict[key]+KeyError；用isinstance()或hasattr()预检，而非靠异常兜底 - 若必须在循环中处理多种类型输入，优先用
if/elif分支判断类型或结构，而不是“先抛再抓” - 用
timeit对比：对 10 万次操作，dict.get()通常比try/except快 3–5 倍
空 except: 是调试噩梦的起点
except: 或 except Exception: 不带具体异常类型，会吞掉 KeyboardInterrupt、SystemExit 甚至内存不足等关键信号，让程序卡死、假死或无法被 Ctrl+C 中断。
更隐蔽的问题是掩盖真实逻辑缺陷：比如本该报 TypeError 的地方被静默吃掉，后续变量变成 None，错误在下游才暴露，堆栈已丢失原始位置。
立即学习“Python免费学习笔记（深入）”；
实操建议：
- 永远明确写出要捕获的异常类型，例如
except ValueError:、except requests.RequestException: - 如需兜底日志，至少保留
except BaseException:并立即raise，或只记录后sys.exit(1) - 用
pylint配置W0702（bare-except）警告，CI 中强制拦截
异常链滥用让错误溯源变困难
Python 3 支持 raise new_exc from old_exc，但过度嵌套（比如每层都 raise from）会让 traceback 变得冗长，真正出问题的那行代码被埋在十几层“During handling of the above exception…”之后。
常见于封装 SDK 或中间件时，开发者习惯性“包装异常”，却没判断是否真有必要传递上下文。
实操建议：
- 只在需要补充业务语义时用
from：比如数据库操作失败，包装成BusinessLogicError并raise from db_exc - 纯日志记录场景，用
logging.exception()即可，不必重新raise - 避免三层以上异常链；超过两层时，考虑直接记录原始异常并抛出新异常（不带
from），保持 traceback 干净
自定义异常没继承 Exception 的后果
写 class MyError: pass 而非 class MyError(Exception): pass，会导致它无法被 except Exception: 捕获——因为 Exception 是所有内置异常的基类，而用户类默认继承 object。
这会造成两种典型故障：一是调用方以为能兜住所有异常，结果漏掉你的错误；二是测试中 mock 异常失败，因为 patch 目标错了基类。
实操建议：
- 所有自定义异常必须显式继承
Exception（或其子类如ValueError、RuntimeError） - 按语义分层：业务异常继承
BusinessError(Exception)，底层错误继承IOError等已有类型 - 在
__init__中调用super().__init__(message)，确保兼容所有异常处理工具（如 Sentry）
异常不是控制流替代品，也不是日志占位符。最常被忽略的点是：很多人在写完 try/except 后，既没加注释说明为什么这里可能出错，也没验证 catch 后的逻辑是否真的能继续执行——这种“写了等于没写”的异常处理，比不写还危险。
