Python 日志级别的设计与使用建议

DEBUG日志生产环境默认不可见，因根logger默认级别为WARNING，低于该级的日志被直接丢弃；需同时设置logger和handler的level才能生效。

为什么 DEBUG 日志在生产环境默认看不到

因为 python 的 Logging 模块默认根 logger 级别是 WARNING，所有低于该级别的日志（DEBUG、INFO）会被直接丢弃，不经过 handler。这不是配置错误，而是设计使然——避免开发期日志污染生产输出。

常见误操作是只改了 handler 的 level（比如给 streamHandler 设置 setLevel(logging.DEBUG)），却忘了同时调高 logger 本身的 level：

logger = logging.getLogger(__name__) logger.setLevel(logging.DEBUG)  # ← 这行必须有 handler = logging.StreamHandler() handler.setLevel(logging.DEBUG) logger.addHandler(handler)

• logger 和 handler 的 level 是“双重过滤”：日志先过 logger 级别，再过 handler 级别
• 若用 basicConfig()，它只设置根 logger 和默认 handler，但不会覆盖已存在的 logger 配置
• 第三方库（如 requests、urllib3）也用 logging，它们的 logger 默认继承根级别，所以开 DEBUG 后可能刷出大量底层请求细节

INFO 和 WARNING 的边界怎么划

关键不是“严重程度”，而是“是否需要人关注”。INFO 应描述可预期的正常流程节点（如服务启动、定时任务开始、API 成功返回），而 WARNING 表示发生了异常但未中断流程（如降级启用、缓存失效、字段缺失但有兜底）。

• 不要把参数校验失败打成 INFO，那是业务异常，至少 WARNING；如果影响下游，应 Error
• 数据库连接重试第 1 次失败 → WARNING；重试 3 次全失败 → ERROR
• 用户主动触发的导出任务完成 → INFO；后台定时同步失败 → WARNING（因为没人盯着看）

自定义日志级别真的有必要吗

绝大多数项目不需要。Python 支持用 logging.addLevelName() 注册新级别（如 TRACE），但会带来三个实际问题：

立即学习“Python免费学习笔记（深入）”；

• 日志分析工具（elk、sentry）通常只识别标准五级，自定义级别可能被忽略或归为 UNKNOWN
• 团队协作成本上升：新人得查文档才知道 TRACE 比 DEBUG 更细，且含义是否和你一致
• Filter、Formatter、Handler 的逻辑都要额外适配，容易漏掉某处判断

更轻量的做法是用 DEBUG + 结构化字段区分粒度：logger.debug("cache hit", extra={"subsystem": "redis", "trace_id": tid})，再通过日志平台的字段过滤替代级别膨胀。

为什么 ERROR 日志里经常缺 traceback

因为直接写 logger.error("failed to process") 不会自动捕获异常上下文。必须显式传入 exc_info=True 或使用 logger.exception()（它是 error(..., exc_info=True) 的语法糖）。

try:     risky_call() except ValueError as e:     logger.error("value error occurred", exc_info=True)  # ← 正确     # 或等价写法：     # logger.exception("value error occurred")

• logger.error("msg", exc_info=e) 也可以，但 e 必须是 Exception 实例，不能是字符串
• 在 except 块外想记录最近一次异常？用 sys.exc_info()，但注意它只在异常处理上下文中可靠
• 异步场景（如 asyncio）中，未被 await 的协程抛出的异常可能丢失 traceback，需配合 loop.set_exception_handler

日志级别本身不难配，难的是让每条日志在出问题时真能帮上忙——这意味着要时刻想着“谁会看这条日志？他需要什么信息才能快速定位？”而不是仅仅填满 level 字段。