subprocess.run()没报错却执行失败的根本原因是check=False（默认），它不主动抛异常，需显式检查returncode或设check=True触发CalledProcessError。
subprocess.run() 为什么没报错却没执行成功
根本原因不是 subprocess.run() 本身静默，而是你没告诉它“出错了要说话”。默认情况下它只返回 CompletedProcess 对象，哪怕命令返回非零退出码（比如 ls /root 被拒绝），它也照常返回、不抛异常、不打印任何东西。
常见静默场景：
-
check=False（默认值）：这是最常被忽略的点，函数不会主动 raise 异常 - 捕获了输出但没检查
result.returncode，比如只看了result.stdout就认为成功 - 错误输出被重定向到
stderr，而你只打印了stdout - 子进程崩溃在 exec 阶段（如命令不存在），
run()会抛FileNotFoundError，但若外层 try/except 吞掉了，就真静默了
如何让失败立刻暴露出来
加 check=True 是最直接的办法——它会让任何非零退出码立刻触发 subprocess.CalledProcessError，附带完整命令、退出码、stdout 和 stderr。
但要注意这不等于“万能开关”：
立即学习“Python免费学习笔记（深入）”；
-
grep找不到匹配时返回 1，这是业务正常行为，不是错误；设check=True会误判 -
diff文件不同也返回 1，同样不该当异常处理 - 真正该用
check=True的是那些“非 0 就算失败”的命令，比如cp、ffmpeg、pip install
更稳妥的做法是显式检查退出码：
Secure Python Code Sandbox
下载
安全 Python 代码沙箱：在隔离的沙箱中执行任意 Python 代码，预装 requests、NumPy、pandas 库。返回 stdout、stderr。
result = subprocess.run(['ls', '/nonexistent'], capture_output=True, text=True)
if result.returncode != 0:
print("命令失败:", result.stderr)
stderr 被吞掉的三个典型原因
即使你加了 capture_output=True，也可能看不到错误信息，因为 stderr 没被正确路由或读取。
- 没传
text=True：返回的是 bytes，直接 print 会显示b'Permission denied\n'，容易被当成空或乱码忽略 - 用了
stdout=subprocess.PIPE却漏了stderr=...：错误流仍输出到终端或被丢弃，result.stderr是空的 - 子进程自己重定向了 stderr（如命令末尾加
2>/dev/null）：Python 层根本收不到，得去改命令本身
推荐统一写法：
result = subprocess.run(cmd, capture_output=True, text=True, timeout=30) # 这样 stdout/stderr 都是 str，可直接 .strip() 或 in 判断
静默失败常和这三类环境问题绑定
很多看似“没报错”的现象，其实是命令压根没跑起来，或者跑在了错误上下文中。
-
PATH不一致：脚本里调用ffmpeg成功，但 cron 里失败，大概率是 cron 的PATH没包含 ffmpeg 安装路径 - 权限路径受限：macOS 上
ls /usr直接返回 1 且stderr为空（SIP 机制），不是 Python 问题，是系统级拦截 - 工作目录错位：命令里用了相对路径（如
./tool），但run()没指定cwd=...，导致找不到文件
验证方法很简单：把同一行命令复制到 shell 里手动执行，看是否真失败、失败时输出什么。如果 shell 里也静默，那问题一定在命令或系统层面，不在 Python。
最容易被忽略的是：错误可能发生在子进程启动前（如找不到可执行文件），也可能发生在运行中（如磁盘满导致 cp 失败），这两类错误的 returncode 和 stderr 表现完全不同，必须分开对待。
