subprocess 阻塞主因是子进程 stdout/stderr 缓冲区填满后挂起，因父进程未及时读取；需用 communicate()、实时读取或 asyncio 替代裸 Popen。
Python 的 subprocess 容易阻塞，核心原因在于**子进程的 stdin/stdout/stderr 缓冲区未及时读写，导致管道填满后挂起**。这不是 bug，而是 Unix 管道机制的自然行为——当一端不消费数据时，另一端写入就会被系统暂停。
stdout/stderr 缓冲区填满是主因
子进程输出（尤其是大量输出）会先写入内核管道缓冲区（通常只有 64KB 左右）。如果父进程没调用 communicate()、readline() 或 iter(proc.stdout, ...) 主动读取，缓冲区很快占满，子进程在下一次 print 或 write 时就会阻塞等待空间释放。
- 常见于运行
ping、ffmpeg、日志输出密集的脚本等场景 -
proc.stdout.read()在无 EOF 时会一直等，而很多命令不会主动关 stdout - 即使只重定向了
stdout=PIPE，若忽略stderr，stderr 仍连到父进程终端或默认管道，也可能造成干扰
wait() 和 poll() 不等于“不阻塞”
proc.wait() 会阻塞直到子进程退出；proc.poll() 虽非阻塞，但仅检查退出状态，**完全不处理 I/O 流**。如果你没同步读取输出，子进程早就在 stdout 写入时卡住了，poll() 返回 None 只说明它还在跑——可能正堵在管道上。
- 错误做法：
proc = subprocess.Popen(...); proc.wait()（没读输出） - 正确思路：要么用
communicate()（自动读完再 wait），要么边运行边实时读（如用线程或select）
交互式命令需要额外注意换行和 flush
运行 python -i、gdb 或自定义 CLI 时，子进程常依赖行缓冲或手动 flush。若 Python 发送命令后不加 \n，或子进程因 stdout 未 flush 而不响应，就会看似“卡住”。
立即学习“Python免费学习笔记（深入）”；
- 发送输入后务必加换行符：
proc.stdin.write(b'print(1)\n') - 必要时调用
proc.stdin.flush()强制送出 - 对交互式程序，推荐用
pexpect或pty模块替代裸Popen
跨平台差异放大问题
Windows 默认管道缓冲区更小，且 select 不支持管道，导致 subprocess 在 Windows 上更容易出现“假死”。Linux/macOS 虽支持 select 或 poll，但若未正确使用（比如只监控 stdout 却忽略 stderr），依然会因 stderr 填满而阻塞。
- Windows 下避免单独重定向
stdout=PIPE而留stderr=None（stderr 会继承控制台，但可能触发 UI 等待） - 统一做法：显式设置
stderr=STDOUT或stderr=PIPE，并一并读取 - 生产环境建议用
asyncio.create_subprocess_exec替代同步调用
