Python logging 模块的正确配置方式

basicConfig 大概率不生效，因为它仅在 root logger 未被配置时才起作用；一旦第三方库（如 requests、django）提前初始化日志，它即失效且无警告。

为什么 basicConfig 大概率不生效？

因为 basicConfig 只在 root logger 尚未被配置过时才起作用。一旦你或某个第三方库（比如 requests、urllib3、django）提前调用了 Logging.debug() 或初始化了 handler，它就彻底失效——连 warning 都不会报。

• 常见触发点：import requests 后首次发请求；import scrapy；Django 启动时自动配置日志
• 验证方法：打印 logging.getLogger().handlers，非空即已被占位
• 正确做法：要么在所有 import 之前调用 basicConfig（极难保证），要么直接放弃它，手动配置 root logger

如何安全地重置并接管 root logger？

清空已有 handlers 并显式设置 level 和输出目标，比依赖 basicConfig 更可靠，尤其在复杂项目或测试环境中。

• 必须先清空：logging.getLogger().handlers.clear()
• 再设 level：logging.getLogger().setLevel(logging.INFO)（注意不是 basicConfig(level=...)）
• 添加 handler 示例：

  handler = logging.StreamHandler() formatter = logging.Formatter('%(asctime)s %(levelname)s %(name)s: %(message)s') handler.setFormatter(formatter) logging.getLogger().addHandler(handler)

• 警告：不要在模块顶层多次执行这套操作，否则会重复加 handler，导致日志刷屏

为什么你的日志里没有文件名和行号？

默认 formatter 不包含 %(filename)s、%(lineno)d 或 %(funcName)s，而只靠 %(name)s 很难定位到具体代码位置。

• 调试阶段建议用：%(asctime)s %(levelname)-8s %(filename)s:%(lineno)d %(funcName)s - %(message)s
• 生产环境可精简掉 %(funcName)s（有性能开销，尤其高频日志）
• 注意：%(filename)s 是不含路径的文件名；如需完整路径，改用 %(pathname)s
• 如果看到 或空字段，说明 formatter 没生效，检查是否 handler 被重复添加或 logger 被禁用

多模块协作时，子 logger 为啥不输出？

子 logger（如 logging.getLogger('db.query')）默认继承 root 的 level，但它的 propagation 默认为 True——意味着日志会“冒泡”到 root 输出一次；但如果 root 没 handler，或子 logger 自己没 handler 且 propagation 关闭，就彻底静音。

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

• 典型误配：logger = logging.getLogger('myapp'); logger.propagate = False，但忘了给它加 handler
• 推荐模式：只配置 root handler，所有子 logger 设 propagate=True（默认值），靠 name 区分来源
• 需要独立输出？给子 logger 单独加 handler，但记得 propagate=False，避免重复打印
• 别用 logger.setLevel(logging.DEBUG) 直接压低子 logger 级别——这会让它把 DEBUG 日志传上去，但 root 可能只收 INFO+，结果是“看似设了却没输出”

日志配置真正的难点不在语法，而在时机和层级关系——哪个模块先动了 root，谁悄悄关了 propagation，formatter 有没有被覆盖，这些细节一错，日志就消失得无声无息。