Python 日志重复输出：沿 logger 层级找到多余的 handler
一条 logger.info 在终端出现两次，未必是函数执行了两次。Python 日志记录可能先由当前 logger 的 handler 输出，再传播到父级 handler，于是同一条记录被写到相同目的地多次。本文依据 Python 3.14 logging 标准库，适合排查单进程中的常见配置问题；多进程与外部采集器还需要单独核对。
AI生成概念配图：日志沿层级汇入输出端，多余的重复路径被识别。仅辅助理解，不代表真实界面或实测结果。
先用独立进程重现层级传播
import logging
logging.basicConfig(level=logging.INFO, format='root: %(message)s')
logger = logging.getLogger('demo.worker')
handler = logging.StreamHandler()
handler.setFormatter(logging.Formatter('child: %(message)s'))
logger.addHandler(handler)
logger.warning('one event')在没有其他配置的新进程中，示例会输出 child 和 root 两条信息。logger 的 propagate 默认开启，记录通过当前 logger 的检查后还会交给祖先的 handler。这里同一条业务事件只有一次调用，重复来自处理路径。诊断真实程序时，可以临时加入 logger 名、进程号和事件标识，先确认是否真的是同一个事件。
getLogger 使用相同名称会返回同一个 logger。若工具函数每调用一次就创建并添加一个新的 StreamHandler，处理器会不断累积，输出次数也可能逐步增加。Web 热重载、测试反复初始化和交互式环境重复运行单元，都可能让这种配置错误更明显。不要把初始化代码放进每次业务请求的执行路径。
检查当前层与祖先层的处理器
current = logging.getLogger('demo.worker')
while current is not None:
print(current.name, current.propagate,
[type(h).__name__ for h in current.handlers])
current = current.parenthandlers 只表示当前 logger 直接挂载的处理器，而 hasHandlers() 还会沿允许传播的祖先查找，因此二者不能互相替代。排查时还要核对 handler 的目标、级别和过滤器，避免看到两个处理器就认为必定重复：一个写文件、一个写终端可能正是设计目标。不要把包含敏感路径或配置的完整对象转储到公共日志。
选定一个明确的配置所有者
对简单应用，常见方案是只在入口配置根 logger，各模块仅获取自己的命名 logger 并记录事件。下面是另一个应在新进程运行的修正版，不是接着上面的重复示例执行；旧进程里已经添加的 child handler 不会凭空消失。
import logging
logging.basicConfig(
level=logging.INFO,
format='%(levelname)s %(name)s %(message)s'
)
logger = logging.getLogger('demo.worker')
logger.info('one event')如果某个日志通道确实需要完全独立的输出，也可以给它配置自己的 handler 并关闭 propagate，但必须确认不会因此失去统一审计或告警。不要把所有 logger 的传播一律关闭来消除重复；那可能只是把应该交给根处理器的记录悄悄丢掉。库代码通常应把最终输出配置交给应用决定。
不要用强制重配掩盖框架配置
根 logger 已有 handler 时，basicConfig 默认可能不再添加新配置，所以“调用了却没生效”需要先看当前状态。force=True 会移除并关闭已有根处理器，只应由明确拥有整个应用日志配置的入口谨慎使用，不适合在第三方库或请求处理函数中随意执行。需要移除自有处理器时，应使用对应 API 并正确关闭资源。
还要区分 logger 级别与 handler 级别：传播的记录直接进入祖先的 handler，不会重新经过祖先 logger 的级别和过滤器。若想限制某个输出目的地，应检查那一层 handler 的设置，而不是只调高父 logger 级别后就期待所有子日志消失。
把输出次数纳入测试
用独立测试进程初始化一次，发送带唯一事件标识的记录，核对每个预期目的地的次数；再测试重复初始化是否按设计无变化。如果应用侧只有一次，而日志平台出现两次，就继续检查标准输出与文件是否被同时采集。最终目标是让每条处理路径有明确归属，既不重复，也不漏掉重要事件。
