Python logging不输出到控制台？StreamHandler移除或设置级别过高导致的日志不显示排查
最常见原因是 root logger 的 StreamHandler 被移除或其级别设为 WARNING 以上，导致 INFO 日志被过滤；需检查 handlers 是否为空、各级别设置，并补全 StreamHandler 与 root 级别。
为什么 logging.info() 调用后控制台完全没输出？
这事儿挺常见：你明明调用了 logging.info()，控制台却一片寂静。问题根源，十有八九出在默认的 root logger 身上——要么是它的 StreamHandler 被悄无声息地移除了，要么就是这个 handler 的级别门槛设得太高（比如设成了 WARNING），把你发出的 INFO 级别日志给直接过滤掉了。
要知道，Python 的 logging 模块在启动时，确实会自动为 root logger 配上一个默认的 StreamHandler（输出到标准错误流 stderr）。但这个“默认配置”相当脆弱。只要代码里调用了诸如 logging.getLogger().handlers.clear()、在 logging.basicConfig() 里传了自定义的 handlers=... 列表，或者手动执行了 logger.removeHandler(...)，都可能把这个关键的输出通道给“干掉”。
- 首先，检查项目启动代码，看是否调用了
logging.basicConfig()并传入了空的handlers=[]，或者自定义的 handler 列表里偏偏漏掉了StreamHandler。 - 其次，全局搜索一下代码中是否有
.removeHandler或.handlers.clear()的调用。这里要特别留意，有些第三方库在初始化时，也可能“偷偷”执行这些操作。 - 最直接的诊断方法是在运行时打印
logging.getLogger().handlers，看看列表长度是否为 0。如果不为 0，那就得逐个检查每个 handler 的h.level（级别）和h.stream（输出流）了。
如何快速恢复控制台输出？
遇到这种情况，没必要大动干戈去重写整个 logging 配置。我们的目标是“最小干预”：给 root logger 补上一个能用的 StreamHandler 就行。
这里有两个关键点必须同时满足：一是补上的 handler 自身级别要合理（至少不能高于你想输出的日志级别）；二是 root logger 本身的级别也不能卡得太死（它的默认级别是 WARNING，必须显式设为 INFO 或更低，才能让 INFO 日志通过）。
立即学习“Python免费学习笔记（深入）”；
- 执行
logging.getLogger().setLevel(logging.DEBUG)—— 先把 root logger 接收日志的门槛降到最低。 - 执行
logging.getLogger().addHandler(logging.StreamHandler())—— 补上一个默认输出到 stderr 的 handler。 - 如果想将日志输出到标准输出流 stdout（而不是 stderr），需要显式传入
stream=sys.stdout参数：logging.StreamHandler(sys.stdout)。 - 补充完成后，立刻试试
logging.info("test")，如果控制台有输出，就说明修复生效了。
basicConfig() 不生效？可能是调用时机或参数冲突
很多开发者喜欢用 logging.basicConfig() 来快速配置，但常常发现它“失灵”了。这是因为 basicConfig() 有一个重要特性：它只在 root logger 尚未添加任何 handler 的时候才会生效。一旦 root logger 已经有了 handler（哪怕只有一个），它就会直接返回，什么也不做。
这就引出了一个常见陷阱：你在 import logging 之后立刻调用了 basicConfig()，自以为是最早的配置。但没想到，某个比你更早导入的模块（比如某些框架、配置加载器）已经触发了 logging 机制，悄悄地创建了 handler。
- 解决方案是把
basicConfig()的调用，挪到真正首次打日志之前的**第一行可执行语句**处，比如放在if __name__ == "__main__":代码块的开头。 - 尽量避免混用
basicConfig()和手动操作 handler 的代码。二者选其一，否则它们很容易互相覆盖，导致配置混乱。 - 如果一定要用
basicConfig()，并且确定需要覆盖现有配置，可以加上force=True参数（Python 3.8+ 支持）。但要注意，这会强制重置并清空已有的 handlers，可能会影响到其他模块已经注册的 handler。
为什么加了 StreamHandler 还是没输出？查 stream 和 encoding
有时候，handler 创建了，级别也设置对了，可控制台依然静默。这时候，问题可能出在更底层——handler 所绑定的流对象本身。
比如，流（stream）可能已经被关闭、被重定向到了文件、或者因为终端编码不匹配导致写入失败（在 Windows 环境下处理中文路径或内容时尤其常见）。
典型的症状是：日志在 IDE 的内置控制台里不显示，但在系统的原生终端（如 cmd、PowerShell 或 Terminal）里却正常；或者只在某些特定的部署环境（如容器、CI）中间出问题。
- 检查
handler.stream属性，确认它确实是sys.stderr或sys.stdout。如果它是一个文件对象，则需要确认文件路径可写且没有被其他进程锁定。 - 在 Windows 下，如果使用的是旧版的 cmd 终端，遇到 Unicode 字符（例如中文）可能会静默失败。可以尝试在创建
StreamHandler时，临时加上encoding="utf-8"参数。 - 在某些容器或 CI（持续集成）环境中，
sys.stderr/dev/null（类 Unix 系统的空设备）。这时，即使 handler 存在，日志也无处可去。用print(repr(sys.stderr))快速验证一下输出流的状态是个好办法。
