Python 标准输出缓冲：已经 print 了一行，重定向文件为什么还看不见
脚本在终端逐行显示进度，重定向到文件后却很久没有新内容，结束时才一起出现。先确认程序有没有走到 print，再检查标准输出的缓冲方式。正常交互终端通常采用行缓冲，重定向到普通文件时通常采用块缓冲，换行未必立即送出去。
让子进程停在已经打印之后
只在运行结束后读文件，三种写法可能得到完全一样的内容，无法解释中途为何看不见。下面用两条独立通道建立观察点：子进程向标准输出打印 tick，再从标准错误发送 ready；随后等待标准输入，暂不退出。
父进程读到 ready 后检查文件，再发一个换行让子进程结束。这样不用睡眠猜测“应该已经打印了”，也不会把机器调度快慢当成证据。所有写入都在自动清理的临时文件内。保存为 demo.py，用 python demo.py 运行。
AI概念示意图：消息可以停留在发送端缓冲区，主动刷新会把已有内容交给下层。
import subprocess
import sys
import tempfile
child = r"""
import sys
mode = sys.argv[1]
print("tick", flush=(mode == "flush"))
print("ready", file=sys.stderr, flush=True)
sys.stdin.readline()
"""
cases = [("default", []), ("flush", []), ("unbuffered", ["-u"])]
for mode, options in cases:
with tempfile.TemporaryFile() as target:
command = [sys.executable, "-I", *options, "-c", child, mode]
with subprocess.Popen(command, stdin=subprocess.PIPE,
stdout=target, stderr=subprocess.PIPE,
text=True) as process:
assert process.stderr.readline() == "ready\n"
target.seek(0)
before = target.read()
_, errors = process.communicate("\n", timeout=5)
assert process.returncode == 0 and errors == ""
target.seek(0)
after = target.read()
expected = b"" if mode == "default" else b"tick\n"
assert before == expected and after == b"tick\n"
print(mode, "before:", repr(before), "after:", repr(after))default 的 before 是空字节串，after 才出现 tick 和换行；flush 与 unbuffered 在 before 就能读到同样内容。三组最终文件相同，所以本次差别在可见时机。代码用断言核对内容，没有用经过多少毫秒决定通过与否。
把刷新设置放到真正写出内容的一端
print 的 flush=True 会在这次打印后刷新目标流，适合关键进度行。启动解释器时加 -u，则让标准输出与标准错误采用无缓冲方式；环境变量 PYTHONUNBUFFERED 也提供相关控制。这里显式传 -u，避免读者依赖外部环境。
子进程还带有 -I 隔离选项，因此不会把调用环境中的 PYTHONUNBUFFERED 继承成隐藏前提。ready 行单独显式刷新，确保握手本身能够到达。它只标记子进程已经越过那次 print，不承担业务任务成功与否的含义。
在父进程设置 Popen 的 bufsize，主要控制父进程创建的管道文件对象，不能指望它替子进程刷新自己的标准输出。本例直接把子进程标准输出接到文件，能把问题收窄到写出一端，而不是父进程怎样读取管道。
换行、刷新与落盘分别验收
行缓冲依赖换行边界。改成没有换行的进度文字后，即使面对终端也可能暂时看不见，应按需要主动刷新。反过来，给重定向输出加换行，并不会自动把它从块缓冲改成行缓冲，本文第一组就是反例。
刷新把 Python 流中积累的数据交给下层，不承诺磁盘断电后仍能恢复，也不保证远端日志平台已经展示。若生产端刷新后仍延迟，应继续检查管道接收器、采集器及展示端；重复打印同一记录通常只会产生重复日志。
排查标准流时可查看 isatty 和 line_buffering，记录当前目标与缓冲设置；这些属性帮助确认运行条件，仍需像示例一样观察数据是否真的到达接收位置，才能验证完整路径。
频繁刷新会增加小批写入的次数，适合需要及时观察的关键消息，未必适合每个字符。可按一条完整进度或一个批次设计刷新边界，再用真实负载衡量成本。本例没有给出跨平台的吞吐数字。
正常退出通常会处理剩余缓冲，所以不能用“最后文件完整”证明运行中实时可见。强制终止和异常关闭又有不同边界，应由任务协议记录完成状态。交互笔记本或测试框架还可能替换标准流，本例验证的是独立 CPython 子进程。
参考资料
资料核对日期：2026年10月2日（北京时间）。示例在 Linux、CPython 3.12.14 中独立运行。
