Logging.exception() 更适合捕获异常，因为它自动附加完整栈跟踪；而 logging.Error() 默认不带栈，需显式传 exc_info=True 且确保在 except 块中有效。
logging.exception() 为什么比 logging.error() 更适合捕获异常
因为 logging.exception() 会自动附加当前异常的完整栈跟踪（traceback），而 logging.error() 默认只记录消息，不带栈——哪怕你在 except 块里调用它，也不会自动抓取 sys.exc_info()。
实操建议：
- 必须在
except块内部调用logging.exception()，否则它拿不到活跃异常上下文，输出的 traceback 为空或错位 - 不要写
logging.exception(str(e))—— 这会把异常信息转成字符串再传入，反而掩盖原始类型，导致日志中丢失exc_info结构 - 如果想自定义前缀消息，直接传字符串：
logging.exception("处理用户请求时失败")，它会在该消息后追加 traceback
手动传入 exc_info=True 的适用场景
当你不在 except 块中，但又需要记录某个已捕获异常的栈（比如异常被重新抛出、或在装饰器/中间件里统一处理），就得显式传参。
常见错误现象：只写 logging.error("msg", exc_info=True) 却没处在异常上下文中 → 日志里出现 NoneType: None 或空 traceback。
立即学习“Python免费学习笔记（深入）”；
正确做法：
- 先用
sys.exc_info()捕获当前异常三元组：exc_type, exc_value, exc_traceback = sys.exc_info() - 再调用
logging.error("msg", exc_info=(exc_type, exc_value, exc_traceback)) - 或者更简洁：在
except中保存异常，之后任意位置调用logging.error(..., exc_info=True)—— 只要还没退出该except块，exc_info=True就有效
formatter 中 %(exc_text)s 的作用与陷阱
%(exc_text)s 是 Formatter 支持的占位符，用于内联渲染异常栈文本。但它**不会主动触发栈收集**，只负责格式化已存在的 exc_info。
性能影响：开启它会让每条含异常的日志多一次 traceback 格式化开销，纯 info/warn 级别日志若误配该格式器，可能拖慢吞吐。
配置建议：
- 为不同 handler 设置不同 formatter：error handler 用含
%(exc_text)s的，console handler 用精简版 - 避免在 root logger 的 formatter 里无差别加
%(exc_text)s—— 大量非异常日志会被强制尝试提取空 exc_info，徒增开销 - 若需控制栈深度（比如只显示最后 3 层），得自定义 formatter，重写
formatException()方法
结构化日志（如 jsON）中如何保留栈信息
用 json.dumps() 直接序列化日志 record 会丢掉 exc_info，因为它是 tuple + traceback 对象，不可 JSON 序列化。
关键点：必须在 formatter 层就将 exc_info 转成字符串，再塞进 dict。
实操方式：
- 继承
logging.Formatter，在format()中检测record.exc_info，调用self.formatException(record.exc_info)得到字符串 - 把结果赋给
record.exc_text（自定义字段），再在 JSON 模板里引用%(exc_text)s - 别依赖第三方库（如
python-json-logger）的默认行为——有些版本对exc_info处理不一致，上线前务必用真实异常测试输出
最易被忽略的是：即使用了结构化日志，exc_info=True 仍必须显式传入 log 调用，否则 record.exc_info 为 None，后续所有处理都失效。