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 字段。
