Python subprocess 管道死锁时怎么读取 stdout 和 stderr

Python subprocess 同时捕获 stdout 和 stderr 时，最稳妥的读取方式是让 Popen.communicate() 一次完成两条管道的消费与等待。不要先对某一条流调用 read()，再对进程执行 wait()；如果另一条管道先写满，子进程会阻塞，父进程也就像“死锁”一样停住。

解决顺序可以记成一句话：双流都用 PIPE，正常场景调用 communicate；需要时加 timeout，超时先 kill，再调用一次 communicate 把剩余输出收回来。

• 死锁原因：子进程写满 stdout 或 stderr 的管道后等待，父进程却没有同时读取它。
• 最小方案：stdout=PIPE、stderr=PIPE 配合 communicate()。
• 超时方案：捕获 TimeoutExpired 后终止进程，再次 communicate() 完成清理。
• 容量边界：communicate() 会把输出缓存在内存，不适合无限增长的大日志。

stdout 和 stderr 同时捕获时为什么会死锁

当父进程把两条流都设置为 PIPE，操作系统会为它们分别维护缓冲区。子进程可能一边把正常结果写入 stdout，一边把诊断信息写入 stderr。如果父进程先等待子进程结束，或者只循环读取 stdout，stderr 的缓冲区写满后，子进程就会停在写操作上，永远等不到退出；父进程又在等它退出，这就是典型的互相等待。

因此，下面这种顺序有风险：先执行 proc.stdout.read()，再读取 stderr，最后才 proc.wait()。只要 stderr 的输出超过管道可暂存的容量，第一次读取就可能等不到 EOF。具体容量由操作系统和运行环境决定，业务代码不应该依赖某个固定字节数来“保证不会卡”。

用 communicate 一次读取两条输出

普通命令最小写法如下。text=True 让返回值成为字符串；如果需要明确编码，可以同时指定 encoding 和 errors。代码中的 returncode 仍然要检查，因为“读完输出”不代表子进程执行成功。

import subprocess

# 同时接管两条输出管道，避免只读取一侧造成互相等待
proc = subprocess.Popen(
    ["python", "worker.py", "--input", "data.json"],
    stdout=subprocess.PIPE,
    stderr=subprocess.PIPE,
    text=True,
    encoding="utf-8",
    errors="replace",
)

# communicate 会持续消费 stdout 和 stderr，并等待子进程结束
stdout_text, stderr_text = proc.communicate()

if proc.returncode != 0:
    # 保留错误输出，便于日志记录或返回给上层调用者
    raise RuntimeError(f"worker failed: {stderr_text.strip()}")

print(stdout_text)

这里不要再额外调用 proc.wait() 来“确保结束”。communicate() 已经完成读取和等待；多余的 wait() 通常只是让代码意图变模糊。若不需要分别处理两条流，可以把 stderr 指向 subprocess.STDOUT，让两者合并到同一个返回值，但这样会失去区分错误与正常输出的能力。

超时后为什么要 kill 再 communicate

子进程可能不是管道死锁，而是真的执行过久。给 communicate() 加超时后，超时会抛出 TimeoutExpired；这时子进程不会自动替你完成业务清理。正确做法是终止它，再调用一次不带输入的 communicate()，让父进程把剩余管道数据读完。

import subprocess

# 给可能卡住的任务设置上限，并保留两条输出
proc = subprocess.Popen(
    ["python", "worker.py"],
    stdout=subprocess.PIPE,
    stderr=subprocess.PIPE,
    text=True,
)

try:
    stdout_text, stderr_text = proc.communicate(timeout=15)
except subprocess.TimeoutExpired as exc:
    # 先结束子进程，避免超时任务继续占用资源
    proc.kill()
    # 再次 communicate 完成管道收尾，保留超时前后的诊断输出
    stdout_text, stderr_text = proc.communicate()
    raise TimeoutError(
        f"worker timed out; stdout={stdout_text[-500:]!r}; "
        f"stderr={stderr_text[-500:]!r}"
    ) from exc

if proc.returncode != 0:
    raise RuntimeError(stderr_text.strip())

超时后不要改成直接 wait()，也不要把同一个 input 再传给第二次 communicate()。对于树状子进程，还要根据平台和进程模型决定是否需要额外终止子进程组；本文的示例只处理一个由 Popen 直接创建的进程。

输出很大时怎么选读取方式

communicate() 会把 stdout 和 stderr 缓存在内存，适合有限大小的命令结果、编译诊断或一次性工具调用。如果输出可能无限增长，不要用它承接完整日志。可以让输出重定向到文件，再读取文件；或者使用 asyncio.create_subprocess_exec()，在异步任务中设计明确的消费策略。异步接口同样不应只读取一条流后等待另一条流。

如果只是快速执行一个有限输出的命令，subprocess.run() 更简洁；设置 capture_output=True 后，它内部仍会使用管道和通信机制。需要区分“进程启动失败、超时、非零退出码、stderr 内容”时，可以保留 CompletedProcess 或捕获相应异常，不要只判断是否拿到了字符串。

常见问题

为什么 stdout.read() 能运行一会儿才卡住？

因为开始阶段 stderr 可能还没有写满，父进程能顺利读到部分 stdout。等另一条管道达到缓冲上限，子进程阻塞，stdout 也不再继续产生 EOF，读取就像卡死。问题取决于输出交错和大小，不会每次都稳定复现。

communicate() 返回的 stdout 和 stderr 是什么类型？

使用 text=True 或文本模式时返回字符串；默认二进制模式则返回字节。需要处理中文或混合编码时，建议显式给出 encoding 和 errors，避免把解码问题误判成管道问题。

超时后只 kill 不读取输出可以吗？

不建议。只 kill 可能留下未消费的管道数据和不完整诊断信息。终止后再调用一次 communicate()，才能把已经产生的 stdout、stderr 和最终状态收拢起来。

输出量很大还能使用 communicate 吗？

如果大小可控可以使用；如果是持续日志或上限未知的输出，应改用文件重定向或异步、分块消费方案。核心判断不是“命令是否简单”，而是输出是否适合一次性放入内存。

参考：Python subprocess 官方文档、Python asyncio subprocess 官方文档。