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 
获取模块专属 logger（名字体现层级）
db_logger = logging.getLogger('myapp.database') api_logger = logging.getLogger('myapp.api')
各自添加互不干扰的 FileHandler
db_handler = logging.FileHandler('db.log') api_handler = logging.FileHandler('api.log')
db_logger.addHandler(db_handler) api_logger.addHandler(api_handler)
注意：必须设 level，否则默认 WARNING，INFO 不会输出
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() 补充纳秒字段。