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 本身线程安全，但多进程并发写同一文件会破坏内容（如两行日志挤在同一行）。标准库不提供跨进程安全的文件写入机制。
立即学习“Python免费学习笔记（深入）”；
- 单机多进程场景：用
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
<p>log_queue = queue.Queue(-1)
logger = logging.getLogger('myapp')
logger.addHandler(QueueHandler(log_queue))
logger.setLevel(logging.DEBUG)</p><h1>启动监听器（应在主循环前启动）</h1><p>listener = QueueListener(log_queue, logging.FileHandler('app.log'))
listener.start()</p><h1>…你的业务代码…</h1><p>logger.info('This goes to file via queue')</p><h1>程序退出前</h1><p>listener.stop()</p>真正难的不是写日志，而是让日志在复杂部署（gunicorn 多 worker、k8s sidecar、异步任务队列）里保持时间有序、来源可溯、不丢不乱。这些场景下，logging 原生能力很快见底，得靠结构化输出（JSON）、上下文注入（extra 或 filters）、以及外部收集系统配合。
