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（极难保证），要么直接放弃它，手动配置rootlogger
如何安全地重置并接管 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 - 如果看到
<string></string>或空字段，说明 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 有没有被覆盖，这些细节一错，日志就消失得无声无息。
