logging模块非开箱即用，需手动配置Logger、Handler、Formatter；basicConfig仅首次生效；日志按层级继承并向上传播；多进程需避免共用FileHandler，推荐队列或专用收集进程。

logging 模块不是“配好就能用”的黑盒，它默认行为和实际生产需求之间存在明显断层——直接调用 logging.info() 往往日志不输出、格式混乱、多进程下错乱、或根本没写入文件。

为什么 basicConfig() 经常失效？

这是最常踩的坑：basicConfig() 只在 logging 系统未被初始化时生效。一旦任意模块（比如第三方库）先调用了 logging.debug() 或 getLogger()，它就彻底失效，后续再调用也无用。

• 检查是否某处提前触发了日志——常见于 import 时执行了日志语句
• 避免依赖 basicConfig() 做核心配置；改用显式创建 Logger + Handler + Formatter
• 若必须用，确保它是整个程序中第一个日志相关调用，且放在 if __name__ == '__main__': 下

getLogger('a.b.c') 和 getLogger() 的层级关系怎么影响输出？

Python 日志是树状继承体系。getLogger('a.b.c') 创建的 logger 自动继承自 getLogger('a.b') 和根 logger（getLogger() 返回的就是根 logger）。关键点在于：日志会向上传播（propagate），直到遇到设置了 propagate=False 的 logger 或到达根 logger。

• 默认所有 logger 都 propagate=True，所以 getLogger('db.query').error(...) 会同时走自己的 handler 和根 logger 的 handler
• 想隔离模块日志？给子 logger 单独配 handler，并设 logger.propagate = False
• 根 logger 的 level 是最终兜底阈值：即使子 logger 设了 DEBUG，但根 logger 是 WARNING，那 INFO 级别日志仍不会输出

多线程/多进程下日志错乱或丢失怎么办？

FileHandler 本身线程安全，但多进程并发写同一文件会破坏内容（如两行日志挤在同一行）。标准库不提供跨进程安全的文件写入机制。

• 单机多进程场景：用 RotatingFileHandler + delay=True 配合文件锁（如 concurrent-log-handler 第三方包）
• 更稳妥方案：所有进程把日志发到本地 Unix socket 或 UDP 端口，由一个专用日志收集进程落盘（类似 rsyslog 思路）
• 绝对不要让多个进程直接共用同一个 FileHandler 实例
• 注意 QueueHandler + QueueListener 组合可解耦主线程与 I/O，但仅解决线程阻塞，不解决多进程文件冲突

import logging
from logging.handlers import QueueHandler, QueueListener
import queue
log_queue = queue.Queue(-1)
logger = logging.getLogger('myapp')
logger.addHandler(QueueHandler(log_queue))
logger.setLevel(logging.DEBUG)
启动监听器（应在主循环前启动）
listener = QueueListener(log_queue, logging.FileHandler('app.log'))
listener.start()
…你的业务代码…
logger.info('This goes to file via queue')
程序退出前
listener.stop()

真正难的不是写日志，而是让日志在复杂部署（gunicorn 多 worker、k8s sidecar、异步任务队列）里保持时间有序、来源可溯、不丢不乱。这些场景下，logging 原生能力很快见底，得靠结构化输出（JSON）、上下文注入（extra 或 filters）、以及外部收集系统配合。