为什么读取subprocess.stdout时readline会阻塞、无法实时返回子进程输出？

本质是C语言标准库的stdout自动缓冲策略切换导致的数据没有实际写入管道，和Python侧的subprocess、readline逻辑本身无关：

• 当程序的stdout连接到交互式终端（TTY）时，不管是Linux的glibc还是Windows的MSVC C运行时，默认都会采用行缓冲模式：遇到换行符\n就会自动把缓冲区的数据刷入实际输出设备，这也是平时我们在终端跑C程序，printf带\n就能立刻看到输出的原因。
• 但当stdout被重定向到非终端设备（比如这里subprocess创建的管道、或者重定向到本地文件）时，C标准库会自动将stdout的缓冲模式切换为全缓冲：只有当缓冲区被写满、程序正常退出、或者手动触发缓冲区刷新时，缓存的输出数据才会真正通过文件描述符写入管道。

你代码里的三次printf虽然都带了换行符，但因为输出目标是管道不是终端，行缓冲规则不生效，所有的输出内容其实一直留在C程序内部的用户态缓冲区里，根本没有推送到管道的内核缓冲区，因此Python侧调用app.stdout.readline()时拿不到任何数据，只能一直阻塞。直到C程序最终退出时，C运行时会自动清理资源、刷新所有stdio缓冲区，把攒着的三行内容一次性写入管道，Python的readline才会一次性拿到所有之前攒的内容返回。

调整C程序的输出行为 #

• 每次执行printf后，手动调用fflush(stdout);强制刷新stdout缓冲区，让每次写入的内容立刻推送到管道：

  printf("Line 0\n");
  fflush(stdout);
  printf("Line 1\n");
  fflush(stdout);
  printf("Line 2\n");
  fflush(stdout);
  

• 在C程序启动最开始，强制将stdout固定为行缓冲模式，不管输出目标是什么设备，都遇到换行就自动刷：

  // 放在main函数最开头，将stdout设为行缓冲模式
  setvbuf(stdout, NULL, _IOLBF, 0);
  

不修改C程序源码的兼容处理 #

如果无法调整C程序的代码，可以在subprocess启动子进程时，通过stdbuf命令包装应用启动参数，强制调整目标程序的stdout缓冲模式：

• 将原来的启动参数从直接传入应用路径，改为['stdbuf', '-oL'] + 原应用参数列表，-oL参数的作用就是强制让glibc将该子进程的stdout设为行缓冲，不需要修改C程序源码就能实现逐行即时输出。

注：部分场景下会误以为问题出在Python侧的管道读取逻辑上，实际上Python的管道读取逻辑本身没有额外缓存阻塞，只要对端进程将数据写入了管道文件描述符，readline就会立刻返回对应内容，不存在等对端退出才批量返回的设计。

内容的提问来源于stack exchange，提问作者Jack Humphries