线上服务出错时仅用print()无法满足日志需求：无时间戳、模块名、调用栈，且日志混入stdout难以被systemd或logrotate管理；应使用logging.exception()替代，它自动记录完整traceback并强制在except块中调用。
为什么 try/except 里直接 print() 不够用
线上服务出错时，只靠 print() 输出异常信息，基本等于没留证据：没时间戳、没模块名、没调用栈上下文，日志还混在 stdout 里，根本没法被 systemd 或 logrotate 管理。更麻烦的是，一旦捕获了异常但没重新抛出，错误就静默消失了，后续逻辑可能基于错误状态继续执行。
正确做法是把异常交给 logging 模块处理，它能自动记录 exc_info=True 时的完整 traceback，还能按级别、格式、输出目标做统一管控。
- 别在
except块里写print(e)或print(traceback.format_exc()) - 用
logging.exception()替代 —— 它等价于logging.error(..., exc_info=True)，专为异常场景设计 - 确保根 logger 至少有一个 handler（比如
StreamHandler或FileHandler），否则日志会无声丢弃
logging.exception() 和 logging.error() 的关键区别
logging.exception() 是语法糖，但它有强制约束：只能在 except 块中调用，且隐式绑定当前异常上下文（sys.exc_info()）。如果在 except 外调用，exc_info 会是 None，日志里看不到 traceback。
logging.error() 则更灵活，但要手动传 exc_info=True 才能打印堆栈；漏掉这个参数，就只剩一条干巴巴的错误消息。
立即学习“Python免费学习笔记（深入）”；
-
logging.exception("请求解析失败")→ 自动带 traceback，推荐用于except内 -
logging.error("请求解析失败", exc_info=True)→ 效果相同，适合需要动态控制exc_info的场景 -
logging.error("请求解析失败")→ 没 traceback，容易掩盖问题根源
如何让异常日志包含更多上下文信息
光有 traceback 不够，比如同一个函数被多个 API 调用，得知道是哪个请求触发的异常。可以在 logging.exception() 的消息字符串里拼入变量，或用 extra 参数注入字段。
注意：extra 字典里的键不能和 logging 默认字段重名（如 message、levelname），否则会报 KeyError。
- 简单拼接：
logging.exception(f"用户 {user_id} 下单失败，金额 {amount}") - 结构化注入：
logging.exception("下单失败", extra={"user_id": user_id, "order_id": order_id})，前提是 formatter 里用了%(user_id)s这类占位符 - 避免在
extra里传大型对象或未序列化数据，可能引发TypeError
捕获后是否该重新抛出异常
这取决于你的控制流设计。如果异常已记录，但上层还需要决策（比如重试、降级、返回特定 HTTP 状态码），就必须重新抛出；如果这是最终处理点（比如兜底的全局异常处理器），则不必再抛。
常见错误是捕获后仅记录却未抛出，导致调用方收不到异常，流程卡在错误状态。另一个坑是用 raise e 会丢失原始 traceback，应该用裸 raise。
- 要保留原始堆栈 → 用
raise（不带参数） - 要包装异常 → 用
raise NewException("xxx") from e - 绝对不要写
raise e，它会切断 traceback 链 - 异步函数（
async def）中同样适用，但需确保 handler 支持异步写入（如用QueueHandler + QueueListener）
异常日志真正起作用的前提，是你清楚每处 except 的职责边界——是终结？还是中转？这点比日志格式重要得多。
