subprocess.popen卡死的真正原因是pipe缓冲区溢出，而非阻塞；子进程写满64kb管道缓冲区后挂起等待读取，若父进程不及时读取则僵住。
它不是“会阻塞”，而是你没管好 stdout/stderr 管道 —— 一旦缓冲区满，子进程就卡住不动了。
subprocess.Popen 卡死的真正原因：PIPE 缓冲区溢出
当你用 subprocess.Popen 启动一个输出量大的 Shell 脚本（比如持续打印日志、ffmpeg 转码、tail -f），并设置 stdout=subprocess.PIPE，Python 就会为子进程创建一个固定大小的管道缓冲区（通常 64KB）。子进程写满这个缓冲区后，就会挂起等待父进程读取；而如果你在等它结束（比如调用 wait() 或没读就直接退出），父进程又不读，双方僵住 —— 表现就是“脚本卡死了”。
常见错误模式：
- 只调用
proc.wait()，完全不碰stdout - 用
proc.stdout.read()但脚本没结束，导致阻塞在读操作上 - 同时设了
stdout和stderr=subprocess.PIPE，却只读其中一个，另一个满溢导致卡死
subprocess.run() 为什么有时也像卡住？
subprocess.run() 默认是阻塞式，但它内部调用的是 communicate()，所以本身不会因管道满而卡死。但如果你传入了 timeout 值，而子进程真超时了，它会抛出 subprocess.TimeoutExpired 异常 —— 如果你没捕获，程序就崩了；如果捕获后没做 terminate() 或 kill()，那个子进程还在后台跑着，可能继续占资源、写文件、甚至发请求。
关键点：
-
run()安全，但只适合“短时、结果明确”的命令 - 它不支持实时输出 ——
stdout只在进程结束后才返回 - 若你传了
timeout，必须处理异常并手动清理子进程
实时读取 + 防卡死的最小可行方案
要用 Popen 实现实时输出且不卡死，核心是“边跑边读”，不能等。最轻量、最不容易出错的做法是：
import subprocess
import sys
<p>proc = subprocess.Popen(
['your_script.sh'],
stdout=subprocess.PIPE,
stderr=subprocess.STDOUT, # 合并错误流，避免双管道堵一个
text=True,
bufsize=1 # 行缓冲，配合 print(flush=True) 更稳
)</p><h1>实时读取每一行，不积压</h1><p>for line in proc.stdout:
print(line, end='', flush=True)</p><h1>等待结束，获取退出码</h1><p>proc.wait()
if proc.returncode != 0:
print(f"⚠️ 子进程异常退出，码：{proc.returncode}")
</p>
注意事项：
- 别用
readline()加while proc.poll() is None循环 —— 如果某次没输出，循环空转，还可能漏掉最后一行 - 务必设
stderr=subprocess.STDOUT，否则 stderr 管道单独满溢也会卡死 - Shell 脚本里如果有
echo类输出，建议加echo "msg" | tee /dev/stderr或确保每行都刷缓存（stdbuf -oL包裹命令）
超时强制终止必须配 kill()，不是 terminate()
terminate() 发送 SIGTERM，很多 Shell 脚本或后台进程会忽略它；而 kill() 发 SIGKILL，无法被捕获或忽略，才是真正的“拔电源”。尤其当脚本里调用了 ffmpeg、rsync 或 Java 进程时，terminate() 经常无效。
安全超时模板：
try:
proc = subprocess.Popen(['long_script.sh'], stdout=subprocess.PIPE, text=True)
proc.wait(timeout=30)
except subprocess.TimeoutExpired:
proc.kill() # 关键：这里必须用 kill()
proc.wait() # 确保子进程真正退出
raise RuntimeError("命令执行超时，已强制终止")
容易被忽略的一点：即使你调用了 kill()，也要再跟一个 wait()，否则子进程变成僵尸进程，Linux 下会一直挂在 ps 里，直到父进程退出。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
