根本原因是python在非交互式环境下默认启用stdout块缓冲，导致print()输出滞留在内存中未刷新；可通过python -u、pythonunbuffered=1或flush=true三种方式强制实时输出。
Python自动化脚本在非交互式Shell环境下不输出日志，根本原因不是代码写错了，而是标准输出被缓冲了——print()内容卡在内存里没刷到文件或终端。
Python stdout 在非交互式环境默认启用块缓冲
当你在终端敲 python script.py，它是行缓冲（每换一行就输出）；但换成 nohup python script.py &、Docker 后台运行、宝塔面板启动、Keyboard Maestro 调用，或者 /bin/bash -c 'python script.py'，Python 就自动切到块缓冲（等满 4KB 或程序退出才写）。你的脚本每小时只 print 一行，日志文件可能一周都看不到内容。
- 验证方法：在脚本开头加
import sys; print(sys.stdout.isatty())—— 非交互式下返回False - 影响范围：所有基于
print()或未配置flush=True的logging输出 - 注意：即使重定向到文件（如
> app.log），缓冲行为也不会自动消失
修复方案：强制无缓冲输出的 3 种等效方式
核心思路是让 stdout 实时刷新，而不是等缓冲区填满。选一种即可，别叠加使用：
Python 3.14.2是Python编程语言在2025年12月5日发布的稳定版本，属于3.14系列的第二个维护更新。该版本包含了18项修复，重点解决了多进程、数据类及正则表达式等模块的回归问题，并修复了CVE-2025-12084等安全漏洞。此版本标志着自由线程模式（移除GIL）正式获得官方支持，是Python发展的重要里程碑。
- 启动时加
-u参数：python -u script.py（Docker、nohup、crontab 全适用） - 设置环境变量：
PYTHONUNBUFFERED=1 python script.py（适合容器ENV或 systemd service 文件） - 代码内显式刷新：
print("msg", flush=True)或sys.stdout.flush()（适合局部控制，但容易漏）
Docker 和宝塔面板的典型陷阱
这两类环境特别容易踩坑，因为它们天然屏蔽 TTY：
- Dockerfile 中写
CMD ["python", "app.py"]→ 必须改成CMD ["python", "-u", "app.py"]或加ENV PYTHONUNBUFFERED=1 - 宝塔面板部署 Python 项目时，日志路径指向的是
error.log，但你的print()默认进stdout，而宝塔可能只捕获stderr—— 建议统一用logging并配置 handler 写文件，别依赖 print - 如果用了
supervisord或systemd管理进程，记得在服务配置里加Environment=PYTHONUNBUFFERED=1
为什么 Keyboard Maestro 或 crontab 也失败？
它们不仅禁用 TTY，还清空用户 shell 环境（PATH、pyenv、venv 都失效），导致连 python 命令都找不到，更别说输出了：
- 先确认实际执行路径：
/bin/bash -c 'which python'，很可能返回空或系统默认/usr/bin/python - 解决方案：用绝对路径调用解释器，例如
/Users/xxx/.pyenv/versions/3.11.5/bin/python -u script.py - 或在脚本开头用
#!/usr/bin/env python -u（注意：shebang 不支持参数，此写法无效；必须用 wrapper shell 脚本封装）
缓冲问题本身不难解决，但容易被误判为“脚本没运行”或“逻辑错误”。真正麻烦的是它和环境隔离（PATH、venv、TTY）耦合在一起，一并爆发——所以排查时，先跑一句 python -u -c "print('test')"，确认输出通了，再查业务逻辑。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
