_popen 用于启动子进程并建立单向管道，返回 FILE* 但需用 pclose 关闭以获取退出码、防僵死；仅 Windows 支持，Linux/macOS 应用 popen；模式仅 "r"/"w"，命令经 cmd.exe /c 解释；注意子进程缓冲导致读取阻塞。
用
_popen
读取子进程输出，别当它是
fopen
_popen
看起来像文件操作，实际是启动新进程并建立单向管道。它返回的是
FILE*
，但背后绑着一个子进程，
fclose
会直接终止它——这和普通文件完全不同。必须用
pclose
，否则子进程可能僵死，资源泄漏，且返回值拿不到退出码。
只支持 Windows（
_popen
/
_pclose
是 MSVC 扩展），Linux/macOS 请改用
popene
或
fork
+
pipe
+
exec
模式字符串只能是
"r"
（读子进程 stdout）或
"w"
（写子进程 stdin），不能加
b
、
+
等修饰
命令字符串会被
cmd.exe /c
包一层（Windows 默认），所以支持重定向、管道符，比如
"dir /b | findstr ".txt""
读不到输出？检查缓冲与阻塞问题
子进程如果输出少、没换行、或用了全缓冲（比如 C++ 的
std::cout
默认行缓存，但重定向后变全缓存），你调
fgets
可能一直卡住。这不是
_popen
的 bug，是管道流控的自然表现。
确保子进程及时刷缓冲：C++ 中加
std::cout 或 std::endl
；Python 脚本加
-u
参数强制行缓冲
不要用
fscanf
或
fread
读不定长输出，优先选
fgets
（带长度防溢出）或
fgetc
单字节轮询
如果子进程长时间不退出，
fgets
会阻塞——需配合线程/超时机制，
_popen
本身不提供非阻塞选项
pclose
返回值不是 0？别忽略它
pclose
返回的是子进程的“伪退出码”，格式和
wait()
一致：低 8 位是信号编号（若被信号终止），高 8 位是退出状态（
exit(n)
的
n
）。直接判断
== 0
很容易误判。
正确提取退出码：
int status = pclose(fp); int exit_code = WEXITSTATUS(status);
（需定义
_CRT_SECURE_NO_WARNINGS
并包含
stdlib.h
）
如果子进程崩溃（如段错误），
WIFSIGNALED(status)
为真，此时
WEXITSTATUS
无意义
未调用
pclose
就丢掉
FILE*
指针，子进程不会自动回收，
Task Manager
里能看到残留进程
路径含空格或特殊字符？命令字符串要手动转义
_popen
不解析引号逻辑，它把整个字符串喂给
cmd.exe /c
。如果你写
"C:My Tools ool.exe arg"
，
cmd
会把
C:My
当命令、
Tools ool.exe
当参数，直接报错“不是内部或外部命令”。
C知道
CSDN推出的一款AI技术问答工具
下载
立即学习
“
C++免费学习笔记（深入）
”；
路径必须双引号包裹：
""C:\My Tools\tool.exe" arg1 arg2"
反斜杠要双写（C 字符串转义），引号要转义（
"
），最终传给
cmd
的是
"C:My Tools ool.exe" arg1 arg2
避免拼接用户输入，否则有命令注入风险；如需动态路径，先用
std::quoted
（C++14）或手写转义函数处理
管道不是万能的文件句柄，
_popen
的生命周期、缓冲行为、错误码解析都和普通 IO 差很远。最常被忽略的是：不调
pclose
就以为完事了，结果子进程在后台偷偷占着内存和句柄。
