Python 日志为什么重复打印？看清处理器与向上传播

Python 日志重复打印通常不是同一行代码执行了两次，而是同一条记录被多个处理器处理，或子记录器继续向父记录器传播。排查时先打印记录器名称、处理器数量和 propagate 状态，再决定是复用配置还是清理旧处理器。本文用最小脚本复现两种重复来源，并给出可重复初始化的配置写法。 为了便于复现，文中会把Python 日志、重复打印、logging分别落到输入、判断和输出三个位置，并用边界样例说明何时应该接受、拒绝或继续排查；同时明确讨论处理器与propagate。

一、先记录谁在输出

日志记录从 logger 创建，经由它的 handlers 处理；如果 propagate 为 True，还会交给父级记录器。根记录器也可能在应用入口被配置。只看终端文字很难判断路径，调试时把 logger 名称、级别和处理器类型打印出来。

如果需要补齐基础概念，可先阅读Python 3 教程，再回到下面的示例核对结果。

import logging
logger=logging.getLogger("shop.worker")
print(logger.name, logger.propagate, len(logger.handlers))

日志记录从 logger 创建，经由它的 handlers 处理；如果 propagate 为 True，还会交给父级记录器。先观察配置对象，再改输出格式，避免通过删掉日志内容掩盖重复。

二、重复添加处理器是最常见陷阱

函数每调用一次就创建 StreamHandler 并 addHandler，会让处理器数量不断增长。模块热重载、测试夹具和多次初始化都可能触发它。配置函数应做到幂等：重复调用后处理器数量不变。

import logging
def configure():
    logger=logging.getLogger("shop")
    logger.setLevel(logging.INFO)
    if not logger.handlers:
        h=logging.StreamHandler()
        h.setFormatter(logging.Formatter("%(name)s %(message)s"))
        logger.addHandler(h)
    logger.propagate=False
    return logger
log=configure(); configure(); print(len(log.handlers))

函数每调用一次就创建 StreamHandler 并 addHandler，会让处理器数量不断增长。if not logger.handlers只能保护这个命名logger，不能替代对父级配置的检查。

三、父级传播会让一条记录走两条路径

命名记录器 shop.worker 的父级是 shop，再往上是根记录器。子级有一个处理器、根级也有一个处理器且 propagate=True 时，同一记录可能输出两次。应用统一由根级配置时，子级通常不应再安装处理器；组件独立输出时，应关闭向上传播。

如果需要补齐基础概念，可先阅读Python3 教程，再回到下面的示例核对结果。

parent=logging.getLogger("shop")
child=logging.getLogger("shop.worker")
print(child.parent.name, child.propagate)

命名记录器 shop.worker 的父级是 shop，再往上是根记录器。传播不是错误本身，关键是团队是否约定唯一输出层。

四、测试输出次数而不是肉眼观察

把日志写入内存流并统计行数，可以稳定验证修复。测试先清理自己创建的处理器，避免测试之间互相污染；生产代码不应在每次请求中重新配置。

import logging
import io
stream=io.StringIO()
h=logging.StreamHandler(stream)
log=logging.getLogger("one-shot"); log.handlers.clear(); log.propagate=False; log.addHandler(h); log.warning("ready")
print(stream.getvalue().count("ready"))

把日志写入内存流并统计行数，可以稳定验证修复。测试期望一条记录输出一次，格式变化应单独断言。

五、边界测试与排错记录

运行三组测试：配置函数调用一次、连续调用两次、子记录器和根记录器同时存在。记录每组处理器数量与输出行数，期望分别为1/1、1/1和按配置约定的唯一输出。再故意把 propagate 改为 True，确认测试能失败；再把 handlers.clear 删除，确认重复初始化用例能抓住回归。

在“Python 日志为什么重复打印？看清处理器与向上传播”这个问题上，把测试结果按“输入、实际输出、预期输出、结论”记录下来；出现失败时保留原始错误和运行环境，不要只截取最后一行。脚本和测试往往会被重复运行，路径、处理器和临时目录不能依赖上一次运行留下的状态。

常见误区与选择建议

不要通过把日志级别调高来隐藏重复；不要在库代码里随意配置根记录器；不要把处理器对象存成全局可变列表却不清理；不要把文件处理器和控制台处理器指向同一轮转文件而不区分职责。

落地检查清单

• 为Python 日志准备一份最小正常输入和一份已知失败输入，先固定环境再比较结果。
• 检查重复打印的边界，明确哪些情况应接受、拒绝或继续排查。
• 记录logging的判断依据，避免错误被默认值、静默重试或格式化输出掩盖。
• 回归时一次只改一个变量，并把失败样例保留在测试目录。
• 交接时写明版本、命令、输入、输出和已知限制，让下一位维护者能复现结论。
• 对照正常输出与失败输出，确认错误信息能指出具体字段、路径、版本或状态，而不是只返回“失败”。
• 若规则发生变化，先更新样例和预期结果，再修改实现，避免测试通过但验收标准已经悄悄改变。
• 最后记录哪些情况尚未覆盖，把它们列为待确认项，不用默认值替代未知结论。

动手练习

1. 先运行正文中的正常样例，保存完整输出。
2. 只改变Python 日志相关的一个输入，确认失败位置符合预期。
3. 再改变重复打印，比较错误信息是否仍然可定位。
4. 关闭一项校验或配置，确认测试能够主动失败。
5. 恢复配置并重跑，检查结果是否回到基线。
6. 把一次失败记录整理成可交接的复现步骤。
7. 将尚未覆盖的边界加入下一轮回归清单。

结果怎么判读

• 输出符合预期且日志完整：记录为通过，并保留输入样例。
• 输出不符合预期但错误位置清楚：记录为可修复失败，先定位规则。
• 输出看似成功但缺少关键字段：不能放行，补充边界校验。
• 同一输入在不同环境结果不同：先比较版本、配置和依赖。
• 修改后正常样例通过、失败样例消失：优先检查错误是否被吞掉。
• 只有把Python 日志、重复打印和logging的证据一起保存，结论才适合交接。

总结

Python 日志重复打印要沿着记录器、处理器和传播路径排查。配置函数保持幂等，明确唯一输出层，再用内存流统计输出次数，修复结果才可复现。

延伸学习

本篇优先补充Python 日志相关的基础资料，再根据项目需要选择课程或笔记。

1. Python 日志基础：Python 入门课程
2. JSON 数据格式教程
3. Python 与 C/C++ 对比笔记

常见问题

Q：为什么logger.handlers为空仍会重复？

A：父级或根记录器可能有处理器，且子级propagate默认为True，要继续检查父链。

Q：每个模块都该创建一个处理器吗？

A：通常由应用入口统一配置；库模块只获取命名logger并记录事件。