CreateProcess启动子进程并重定向stdout需创建匿名管道,设STARTF_USESTDHANDLES、bInheritHandle=TRUE,将管道写端赋给hStdOutput,启动后立即关闭写端,再用ReadFile循环读取;禁用PeekNamedPipe,注意句柄关闭顺序与编码处理。

用 CreateProcess 启动程序并创建子进程 stdout 管道
Windows 下最直接的方式是调用 Win32 API 的 CreateProcess,它支持把子进程的 stdout 重定向到一个匿名管道(PIPE)。关键不是“启动”,而是提前准备好读端句柄,并在 STARTUPINFO 中指定为子进程的标准输出句柄。
常见错误是:没设 STARTF_USESTDHANDLES 标志,或没把管道读端设为继承句柄(bInheritHandle = TRUE),导致子进程无法写入、父进程读不到任何输出。
-
SECURITY_ATTRIBUTES中必须设bInheritHandle = TRUE -
STARTUPINFO.hStdOutput必须赋值为管道写端句柄 -
STARTUPINFO.dwFlags必须包含STARTF_USESTDHANDLES - 启动后立即关闭管道写端(避免读端
ReadFile永远阻塞)
用 ReadFile 异步读取管道数据(避免卡死)
管道默认是同步 I/O,直接调 ReadFile 会阻塞直到有数据或写端关闭。要“异步读取”,实际做法是用 OVERLAPPED + ReadFile,但更轻量且实用的方式是:开一个线程单独循环 ReadFile,每次读小块(比如 4096 字节),并检查返回值是否为 0(表示写端已关闭)。
注意:不能用 PeekNamedPipe 来“预判是否有数据”再读——它不可靠,尤其在子进程输出不规律时容易漏读或假空。
- 每次
ReadFile前清零bytesRead,检查返回值和bytesRead是否一致 - 若
ReadFile返回FALSE且GetLastError() == ERROR_BROKEN_PIPE,说明子进程已退出 - 缓冲区需以
\0结尾再转std::string,否则可能含垃圾字节
为什么不用 std::system 或 _popen?
std::system 完全黑盒,无法获取实时输出;_popen 虽能读 stdout,但它是基于 cmd.exe /c 包装的,会引入额外 shell 层,且不支持设置环境变量、工作目录等,也无法捕获 stderr(除非用 2>&1 拼接,但会混序)。更重要的是:_popen 的读取仍是阻塞式,没有真正异步能力。
如果你只需要简单执行+等结束+拿全部输出,_popen 可用;但只要要求“边跑边读”“响应快”“控制细”,就必须绕过 CRT 封装,直连 Win32 管道机制。
-
_popen内部其实也调CreateProcess,只是封装掉了管道细节 - 某些防病毒软件会拦截
_popen调用,但放行显式CreateProcess -
std::system无法获取子进程 PID,也就无法做超时 kill
字符编码与多字节输出怎么处理?
子进程输出的字节流本身无编码定义。如果目标程序(如 python.exe 或 git.exe)输出的是 UTF-8,而你的控制台是 GBK,直接 wprintf 会乱码。这不是管道的问题,是终端解释问题。
解决方案取决于用途:若只是记录日志,按原字节存文件即可;若要在控制台显示,需先检测 BOM 或用 IsTextUnicode 粗略判断,再用 MultibyteToWideChar(CP_UTF8, ...) 转换。但绝大多数命令行工具(尤其是 Windows 自带)默认用当前 ACP(ANSI Code Page),所以更稳妥的做法是用 GetConsoleOutputCP() 获取当前控制台代码页来解码。
- 不要假设输出一定是 UTF-8 —— cmd.exe 默认不是,PowerShell 5.1 也不是
- 用
SetConsoleOutputCP(CP_UTF8)可临时切换控制台编码,但会影响其他输出 - 若子进程是自己写的,可加参数强制其输出 UTF-8(如 Python 加
-X utf8)
真正的难点不在创建管道,而在正确关闭句柄顺序、区分 EOF 和错误、以及应对子进程意外崩溃导致的句柄残留。Win32 管道对句柄生命周期极其敏感,少关一个、多关一个,都可能导致读端永远等不到 ERROR_BROKEN_PIPE。
C++免费学习笔记(深入):立即使用
在学习笔记中,你将探索 C++ 的入门与实战技巧!











