为什么Python脚本在后台运行时会僵死_解决标准输出缓冲区导致的死锁

先抛个结论：Python脚本一旦切到后台运行，print()输出就可能卡在缓冲区里，看起来像程序僵死。这不是什么玄学，而是标准库的缓冲机制在变。

为什么print()在后台会卡住

Python默认对sys.stdout启用行缓冲——遇到换行符或缓冲区满了才真正往磁盘写。但当你用nohup python script.py &或通过systemd把脚本扔到后台，stdout就不再连接终端（tty）。Python一旦检测到输出目标不是交互式终端，自动切为全缓冲，缓冲区大小通常8KB。如果脚本只输出几行不含换行的文本，数据就一直窝在内存里，外面的日志文件空空如也，看起来就像“僵死”。

如何验证是缓冲区导致的卡顿

最直接的办法：在脚本开头加一句import sys; sys.stdout.flush()，再手动调用一次print("test")后立刻sys.stdout.flush()。如果这时输出能立刻刷到日志，基本锁定的就是缓冲问题。

• 更可靠的方式：用strace -e write -p $(pgrep -f "script.py")观察是否有write()系统调用被阻塞或延迟。
• 对比前台/后台行为：python script.py vs python script.py > /tmp/out.log 2>&1 &，看日志是否延迟落盘。
• 注意：logging模块默认也受stdout缓冲影响，除非显式设flush=True或用StreamHandler配buffering=1。

三种可靠解法及适用场景

别指望print(..., flush=True)逐行加参数——容易漏、难维护。优先用启动参数或环境变量统一控制：

• 方案一（推荐）：启动时加-u参数 ——python -u script.py &。强制stdin/stdout/stderr全部无缓冲，兼容所有Python版本，且不动代码逻辑。
• 方案二：设置环境变量PYTHONUNBUFFERED=1 ——PYTHONUNBUFFERED=1 python script.py &。效果同-u，适合集成进systemd或supervisord配置。
• 方案三：代码内重置stdout ——仅在必须兼容旧环境时用：

  import syssys.stdout = os.fdopen(sys.stdout.fileno(), 'w', 0)  # Python 3.7+# 或更兼容写法：import iosys.stdout = io.TextIOWrapper(    sys.stdout.buffer,    line_buffering=True,    write_through=True)

容易被忽略的连锁反应

缓冲区问题很少是孤立的。它可能掩盖更深层的死锁，比如：

• 子进程通过subprocess.Popen启动后，父进程读proc.stdout但没设bufsize=1或没及时.readline()，导致子进程的stdout缓冲区填满后阻塞写入（尤其子进程也是Python）。
• 使用logging.basicConfig但没传force=True，旧handler残留缓冲行为。
• 容器环境中（如Docker），即使加了-u，若stdout被重定向到/dev/null或管道，仍可能触发glibc层的额外缓冲，此时需配合stdbuf -oL（Linux）。

真正稳定的后台脚本，得把缓冲控制、子进程回收、信号处理三者一起考虑——缓冲只是第一道门，跨过去才发现后面还有坑。