logging.basicConfig() 在导入模块后失效，是因为根 logger 一旦被首次配置（如调用 basicConfig、getLogger 或添加 handler），后续调用将静默忽略；常见原因是第三方库提前触发了 logger 初始化。
为什么 logging.basicConfig() 在导入模块后就失效了
因为 logging 模块的根 logger 一旦被首次配置（比如调用过 basicConfig()、getLogger().setLevel() 或其他 handler 添加操作），后续再调用 basicConfig() 就直接静默返回，什么也不做——这是设计行为，不是 bug。
常见现象：主脚本开头调用了 basicConfig()，但某个第三方库或子模块里提前调用了 getLogger() 并触发了自动初始化，导致你的配置没生效。
- 解决办法：确保
basicConfig()是整个程序中对 logging 的**第一次操作**；更稳妥的做法是彻底不用它，改用显式配置 - 检查是否已有库（如
requests、urllib3）偷偷初始化了 logger，可在启动时加一句print(logging.getLogger().handlers)看是否非空 - 如果必须在多模块中配置，统一在入口文件用
logging.config.dictConfig()或fileConfig()
如何让不同模块日志输出到不同文件且不互相干扰
关键不在 logger 名字，而在 handler 的归属和过滤逻辑。每个 logger 可以有多个 handler，但 handler 本身是共享对象，若多个 logger 共用同一个 FileHandler，就会混写。
正确做法是为每个关注模块创建独立的 logger，并绑定专属 handler：
立即学习“Python免费学习笔记（深入）”；
import logging
<h1>获取模块专属 logger（名字体现层级）</h1><p>db_logger = logging.getLogger('myapp.database')
api_logger = logging.getLogger('myapp.api')</p><h1>各自添加互不干扰的 FileHandler</h1><p>db_handler = logging.FileHandler('db.log')
api_handler = logging.FileHandler('api.log')</p><p>db_logger.addHandler(db_handler)
api_logger.addHandler(api_handler)</p><h1>注意：必须设 level，否则默认 WARNING，INFO 不会输出</h1><p>db_logger.setLevel(logging.DEBUG)
api_logger.setLevel(logging.DEBUG)
- 不要对 root logger 添加 handler，否则所有未显式配置的 logger 都会继承并输出到那里
- 避免重复 addHandler：同一 handler 被多次 add 到同一个 logger 会导致日志重复写入
- 若需按模块隔离又不想手动管理 handler，可用
logging.Filter配合一个共享 handler 实现路由，但复杂度上升，小项目不推荐
logger.debug() 不输出？十有八九是 level 或 propagation 搞错了
DEBUG 不显示，90% 不是因为没调用，而是因为 logger 自身 level 太高，或者它把日志传给了父 logger（默认开启），而父 logger（通常是 root）的 level 是 WARNING。
- 检查当前 logger 的 level：
print(logger.level)，注意NOTSET=0表示继承父级 - 关闭传播：
logger.propagate = False，防止日志向上冒泡到 root，尤其当你已为该 logger 单独配了 handler 时 - 确认 handler 也有对应 level：handler 自身也带 level，默认是
NOTSET，但若你设了handler.setLevel(logging.WARNING)，那即使 logger 是 DEBUG，最终也会被 handler 挡掉 - 别依赖
basicConfig(level=logging.DEBUG)—— 它只设置 root logger 和其 handler 的 level，不影响你手动创建的命名 logger
生产环境必须禁用 StreamHandler，并注意 RotatingFileHandler 的陷阱
开发时用 StreamHandler 打印到终端很爽，但上线后混着 stdout/stderr 输出会干扰容器日志采集（如 Docker、K8s）、破坏结构化日志格式，还可能因缓冲问题丢日志。
换成 RotatingFileHandler 更合适，但要注意几个实际坑点：
-
maxBytes不是硬上限：它只控制单个文件大小，轮转时旧文件可能被重命名（如app.log.1），但不会自动清理，需配合backupCount限制保留份数 - 多进程写同一个日志文件？别这么做。
RotatingFileHandler不是进程安全的，会出现内容错乱或覆盖。应使用WatchedFileHandler（需外部信号触发重开）或改用日志代理（如 syslog、fluentd） - 路径权限常被忽略：确保运行用户对日志目录有写权限，且目录存在——
RotatingFileHandler不会自动创建父目录，得自己用os.makedirs(log_dir, exist_ok=True)
最易被忽略的一点：日志格式中的 %(asctime)s 默认精度只有毫秒，高并发下大量日志时间戳会重复；如需更高区分度，得自定义 Formatter 并用 time.time_ns() 补充纳秒字段。
