Python logging lastResort 怎样处理没有配置 handler 的日志

Python logging 没有配置 handler 时，日志不一定全部消失。只要当前 logger 及其祖先 logger 都没有可用 handler，记录会交给 logging.lastResort；它是一个写向 sys.stderr、级别为 WARNING 的 StreamHandler。因此，排查“为什么没有配置日志却还能看到 warning”时，先看 handler 链路，再看 lastResort。

官方资料：https://docs.python.org/3/library/logging.html#logging.lastResort

lastResort 是无配置场景的兜底出口，不是应用日志的完整配置方案。要控制格式、级别和去向，应显式创建并挂载 handler。

先判断日志有没有可用 handler

一个 logger 记录事件后，会先按自己的配置处理；在允许 propagate 时，事件还会沿父级向上寻找 handler。只要这条链路里有 handler，就走正常处理路径；只有整条链路都没有可用 handler，才会交给 logging.lastResort。

这里的“没有 handler”不是说某个子 logger 的 handlers 列表为空，而是要结合祖先链和传播开关判断。把 handler 挂在 root logger 上时，子 logger 往往也能通过传播找到它；如果中途把 propagate 设为 False，搜索范围会在该 logger 处停止。

所以看到终端里出现一行没有自定义前缀的 warning，不能直接推断“Python 自动配置了完整日志”。更准确的判断是：这条记录可能没有找到显式 handler，随后由默认的 lastResort 输出了最基本的消息。

理解 lastResort 的三个固定属性

Python 官方文档把 logging.lastResort 描述为一个“最后手段”的 handler。它的实现类型是 StreamHandler，目标流是 sys.stderr，级别是 WARNING。这三个属性正好解释了最常见的现象：

• 为什么只有 warning 和 error 明显出现：低于 WARNING 的记录不会通过这个 handler。
• 为什么输出格式很简单：没有为 lastResort 设置应用自己的 Formatter 时，不要把它当成完整日志格式。
• 为什么输出不在 stdout：它写入的是 sys.stderr，与普通标准输出是两条流。

lastResort 只在没有找到其它 handler 时兜底。如果你已经给 root 或目标 logger 挂了 StreamHandler、FileHandler 等 handler，那么记录应由这些显式配置决定；不能仅凭“仍然看到了日志”判断 lastResort 还在工作。

用最小脚本观察 WARNING 边界

下面的脚本只用于理解对象关系。它在独立进程中清理 root logger 的现有 handler，随后打印 lastResort 的类型、级别和输出流，再发出一条 INFO、一条 WARNING 和一条 ERROR。示例没有把输出结果伪装成本文已经在本机执行过的证据。

import logging
import sys

# 在隔离脚本中移除 root logger 的显式 handler，构造无配置场景。
root = logging.getLogger()
for handler in root.handlers[:]:
    root.removeHandler(handler)
root.setLevel(logging.DEBUG)

logger = logging.getLogger("demo.fallback")

# 读取兜底 handler 的三个关键属性，而不是猜测输出去向。
print(type(logging.lastResort).__name__)
print(logging.lastResort.level == logging.WARNING)
print(logging.lastResort.stream is sys.stderr)

# INFO 低于 lastResort 的 WARNING 阈值，WARNING 和 ERROR 才有机会被兜底输出。
logger.info("info 不会由 lastResort 输出")
logger.warning("warning 会进入 lastResort")
logger.error("error 也会进入 lastResort")

阅读这个例子时，重点不是记住某一行终端文本，而是建立判断顺序：先确认没有显式 handler，再确认记录级别达到 WARNING，最后确认观察的是 stderr。若把 stderr 重定向到文件或进程采集器，视觉上可能仍像“日志消失”或“日志跑到别处”，但那是外部收集方式的问题。

用显式 handler 接管输出

应用程序不应依赖 lastResort 来完成长期日志配置。显式 handler 可以确定输出流、级别、格式和资源生命周期。下面把 handler 挂在一个独立 logger 上，并关闭向 root 的传播，避免同一条记录被两个路径处理。

import logging
import sys

# 给应用 logger 建立明确的输出契约，格式和级别由本 handler 决定。
logger = logging.getLogger("demo.application")
logger.setLevel(logging.INFO)
logger.propagate = False

handler = logging.StreamHandler(sys.stdout)
handler.setLevel(logging.INFO)
handler.setFormatter(logging.Formatter("%(levelname)s %(name)s: %(message)s"))

# 避免重复安装同类 handler；真实项目也应在统一初始化入口调用一次。
if not logger.handlers:
    logger.addHandler(handler)

logger.info("这条记录走显式 StreamHandler")
logger.warning("这条记录也不依赖 lastResort")

# 进程结束前释放 handler 持有的输出资源。
handler.flush()
logger.removeHandler(handler)
handler.close()

这段代码使用 stdout 只是为了突出“目的地由显式 handler 决定”，实际服务可以换成 FileHandler、轮转 handler 或项目自己的采集适配器。关键是不要同时让同一 logger 的 handler 和 root handler 都处理同一记录，除非你确实需要两份不同目的地的副本。

basicConfig、propagate 与 lastResort 不要混为一谈

logging.basicConfig() 是便捷的 root logger 配置函数。模块级的 logging.warning() 等调用在 root 没有 handler 时可能自动触发 basicConfig，这与某个命名 logger 在整条祖先链没有 handler 后使用 lastResort，是两条不同的路径。排错时要先确认代码调用的是模块级函数还是命名 logger 方法。

propagate 只决定记录是否继续交给祖先 logger 的 handler，并不等于“开启 lastResort”。如果子 logger 设置了 propagate = False 且自身没有 handler，那么它的搜索范围会缩小；这时仍需要结合实际配置判断是否会落到兜底出口。

不要为了让日志“彻底安静”就随意把 logging.lastResort 改成 None。官方文档说明这样可以恢复旧行为，但生产程序更应该明确配置 handler，并让日志策略在初始化阶段可读、可控、可测试。

按清单定位日志到底去了哪里

1. 确认调用对象：是 root logger、命名 logger，还是模块级便捷函数。
2. 查看目标 logger 的级别、handlers 和 propagate 设置。
3. 沿祖先链检查是否已经挂载 handler，以及传播是否在中途停止。
4. 如果整条链路没有 handler，再检查记录级别是否至少达到 WARNING。
5. 区分 stdout 与 stderr，确认采集器是否只收集其中一条流。
6. 需要稳定格式和目的地时，创建显式 handler，不把 lastResort 当作应用配置。

最后可以把问题压缩成一句话：logging.lastResort 解决的是“没有任何 handler 时，高等级日志还有一个最低限度的出口”，而不是替代完整日志架构。理解 logger 祖先链、传播开关、WARNING 阈值和 stderr 这四个条件，就能解释大多数“没配置却能看到日志”的现象。

常见问题

为什么 logger.info 没有输出，但 logger.warning 有输出？ 通常是因为没有显式 handler，lastResort 的级别为 WARNING，INFO 低于它的处理阈值。

显式添加 StreamHandler 后还会使用 lastResort 吗？ 正常情况下不会。只要 logger 或允许传播到达的祖先 logger 有可用 handler，记录就会走显式处理链路。

lastResort 输出为什么没有我设置的格式？ lastResort 不是你的应用 handler。需要固定格式时，自己创建 handler 并调用 setFormatter()。

怎样判断日志是不是写到了 stderr？ 看采集配置和进程的两条输出流；代码层面可检查 logging.lastResort.stream is sys.stderr，但不要把它当作线上页面验证。

应该把 lastResort 设置为 None 吗？ 只有在你明确需要旧式无 handler 行为并理解丢失提示的代价时才考虑。更稳妥的做法是尽早安装符合业务要求的显式 handler。