subprocess.run()配合capture_output=True和text=True可安全简洁捕获stdout与stderr；手动用Popen易漏wait、未捕stderr、decode错误、无timeout致阻塞，且大输出易内存溢出。
直接用 subprocess.run() 配合 capture_output=True 和 text=True，就能安全、简洁地同时捕获 stdout 与 stderr；别再手动 pipe + decode，也别默认用 subprocess.Popen。
为什么不用 subprocess.Popen 手动管理管道？
很多人一想到“捕获输出”就本能写 Popen，然后自己 .stdout.read()、.wait()、.decode()……这容易漏掉几个关键点：
- 没调
.wait()或没读完流，子进程可能卡住（尤其输出量大时） - 忘记
stderr=PIPE就根本捕不到错误，还误以为程序没报错 - 二进制输出（
bytes）直接.decode()可能抛UnicodeDecodeError，而text=True会自动按系统编码处理 - 没设
timeout，子进程挂起会导致主程序无限等待
subprocess.run() 的正确参数组合
这是最常用也最稳妥的写法，覆盖绝大多数本地命令调用场景：
result = subprocess.run(
["ls", "-l", "/nonexistent"],
capture_output=True,
text=True,
timeout=5
)关键参数含义：
立即学习“Python免费学习笔记（深入）”；
-
capture_output=True：等价于stdout=subprocess.PIPE, stderr=subprocess.PIPE -
text=True：让result.stdout和result.stderr直接是str类型，不是bytes -
timeout=5：必须加，避免子进程失控拖垮主流程 - 不传
shell=True（除非真要解析 shell 语法），否则有安全和兼容性风险
如何区分命令成功但有 warning vs 真正失败？
很多人只看 result.returncode 是否为 0，但很多工具（如 grep、curl）把 warning 输出到 stderr 却仍返回 0。这时得同时检查内容：
-
result.returncode == 0表示进程正常退出，但result.stderr可能非空（比如gcc编译警告） -
result.returncode != 0一定表示出错，此时result.stdout可能含部分结果（如curl -s的响应体），result.stderr含错误原因 - 不要用
if result.stderr:判断失败——空字符串是False，但有些命令出错时 stderr 也可能为空（靠 exit code 才准）
捕获大输出时的内存与性能注意点
capture_output=True 会把全部输出缓存在内存里。如果预期输出超几 MB（比如 tar -cf - /usr），就别这么干：
- 改用
subprocess.Popen配合stdout=.../stderr=...文件对象，边生成边写入磁盘 - 或用
subprocess.run(..., stdout=subprocess.DEVNULL)忽略不需要的内容 - 想实时打印又想保留日志？用
subprocess.Popen+iter(proc.stdout.readline, b"")流式读取，但记得设bufsize=1和universal_newlines=True
真正需要“捕获”的时候，run() 是首选；但输出不可控、不可预估大小，就得退回到更底层的控制逻辑——这点很容易被忽略，直到线上跑出 MemoryError 才反应过来。
