Python logging模块易错点有四：一是basicConfig()仅在root logger无handler时生效；二是忽略propagate致日志重复；三是多线程共用FileHandler引发写入错乱；四是字符串拼接导致非懒加载开销。
Python 的 logging 模块设计严谨、功能强大，但正因为它的灵活性和多层抽象（logger、handler、formatter、filter、level），初学者和经验不足的开发者常在几个关键点上出错——不是模块不好用，而是没理解它“按需组装”的设计哲学。
误以为 basicConfig() 能全局生效
很多人在脚本开头调用 logging.basicConfig(level=logging.INFO)，就以为整个项目日志都按这个配置走。实际上，basicConfig() 只有在 root logger 尚未添加任何 handler 时才生效；一旦某个库或后续代码主动创建了 logger 并加了 handler（比如用了 getLogger(__name__) 后又调 addHandler()），basicConfig() 就彻底失效，导致日志“突然不输出”或“重复输出”。
- 建议：避免依赖
basicConfig()做主配置，尤其在包/模块化项目中；显式配置 root logger 或每个业务 logger - 调试技巧：打印
logging.getLogger().handlers和logging.getLogger('my.module').propagate，确认实际生效的 handler 和传播链
忽略 propagate 导致日志重复
默认情况下，每个 logger 都会把日志向上传播给父 logger（直到 root）。如果你为模块 logger 单独加了 FileHandler，又没关掉 propagate，那同一条日志会先被模块 handler 处理，再传给 root logger 的 StreamHandler，结果终端和文件各打一遍。
- 典型场景：Django 或 Flask 项目中自定义 logger 写入文件，却在控制台看到两份相同日志
-
解决方法：设
logger.propagate = False，或确保 root logger 不额外处理已由子 logger 完整处理的日志
在多线程/多进程里复用 handler 而不加锁
logging 模块本身是线程安全的，但某些 handler（如 FileHandler）内部写文件操作并非原子。多个线程共用同一个 FileHandler 实例时，可能出现日志行错乱、截断甚至写入失败（尤其在 Windows 上）。
立即学习“Python免费学习笔记（深入）”；
- 常见错误：在模块顶层创建一个 handler，所有 logger 都 add 它
- 更稳妥做法：每个 logger 独立持有 handler；或使用
RotatingFileHandler/TimedRotatingFileHandler（它们内部做了基本同步）；必要时手动加logging.handlers.QueueHandler+QueueListener解耦
用字符串拼接代替 lazy 格式化
写 logger.info("User " + user.name + " logged in at " + str(datetime.now())) 看似自然，实则危险：无论当前日志 level 是否允许输出，这些字符串运算和对象访问都会执行，白白消耗 CPU，还可能触发意外副作用（比如 user.name 是 property，访问时抛异常）。
- 正确姿势：用占位符让 logging 延迟格式化 ——
logger.info("User %s logged in at %s", user.name, datetime.now()) - 进阶：配合
logging.LoggerAdapter或自定义 filter 实现条件性计算，进一步节省开销
logging 不难，难在它把责任交给了使用者：你得想清楚“谁记日志、记到哪、怎么记、要不要传上去”。配置写错一次，排查起来往往比写业务逻辑还费时间。
