应直接查看traceback最底层异常行定位根因，如KeyError 'email'在第25行；中间层需用raise...from e保留异常链；避免静默返回None；可通过sys.excepthook完整记录未捕获异常。
直接看 traceback 最底层的异常行
Python 抛出异常时，traceback 是自底向上打印的：最下面那行才是最初触发异常的位置，也就是“根因”。很多人误以为第一行是源头，其实那是调用链终点。比如你看到：
Traceback (most recent call last):
File "main.py", line 42, in <module>
run_pipeline()
File "main.py", line 38, in run_pipeline
process_data(load_config())
File "main.py", line 25, in process_data
return data["user"]["profile"]["email"]
KeyError: 'email'真正出问题的是第 25 行——data["user"]["profile"]["email"] 这一访问，不是 run_pipeline 或 load_config。别被上面几层函数名带偏。
用 raise ... from e 保留原始异常链
中间层函数如果捕获后又重新抛出，必须显式用 raise NewError(...) from e，否则原始异常信息会丢失。否则你会看到一个干净但空洞的堆栈，根本看不出哪层数据结构缺失了键。
- 错：只写
raise ConfigError("invalid user")→ 原始KeyError被吞掉 - 对：写
raise ConfigError("missing 'email' in user profile") from e→__cause__链还在 - 调试时用
print(e.__cause__)或traceback.print_exception(e.__cause__)直接定位根因
避免在中间层静默吞异常或返回 None
这是掩盖根因最常见的方式。比如：
立即学习“Python免费学习笔记（深入）”；
def get_user_email(data):
try:
return data["user"]["profile"]["email"]
except KeyError:
return None # ← 问题在这里调用方拿到 None 后继续往下走，直到某个地方 AttributeError: 'NoneType' object has no attribute 'lower' 才崩，此时 traceback 已完全脱离原始上下文。
- 返回
None不等于“处理了异常”，只是把错误延迟并模糊化 - 要么让异常冒泡（不 catch），要么转换为带上下文的新异常（如
raise MissingFieldError("email", path="user.profile")） - 尤其警惕字典取值、JSON 解析、数据库字段映射这类“看似安全实则脆弱”的操作
用 sys.excepthook 或日志记录完整 traceback
默认的异常打印会截断长 traceback，尤其在嵌套深、模块多时。你可以临时替换全局异常处理器来确保不丢信息：
import sys
import traceback
<p>def debug_excepthook(exc_type, exc_value, exc_traceback):
traceback.print_exception(exc_type, exc_value, exc_traceback)</p><h1>或写入文件：traceback.print_exception(..., file=open("err.log", "a"))</h1><p>sys.excepthook = debug_excepthook注意：sys.excepthook 不捕获被 try/except 拦下的异常，只管未处理的顶层异常。所以它适合兜底，不能替代分层诊断。
真正难的不是看见根因，而是当异常从第三方库、异步回调、或 C 扩展里冒出来时，__cause__ 和 __context__ 可能被意外切断——这时候得靠复现路径 + 日志打点，而不是只盯 traceback。
