绝大多数场景下应优先使用 subprocess.run()；仅当需实时读取输出、交互式通信或长期维持进程时才用 subprocess.Popen()。
subprocess.run() 和 subprocess.Popen() 到底该用哪个
绝大多数场景下，subprocess.run() 是更安全、更简洁的选择；只有当你需要实时读取输出、与子进程交互（比如发信号、写入 stdin）、或长期维持进程生命周期时，才必须用 subprocess.Popen()。
常见错误是看到“高级功能”就默认选 Popen，结果多出大量手动管理逻辑（如 wait()、communicate() 调用时机、stdout 缓冲陷阱），反而容易卡死或丢数据。
-
run()默认会阻塞直到完成，自动处理 编码、超时、异常（CalledProcessError），适合 shell 命令一次性执行（如git status、curl -s） -
Popen不自动等待，不自动解码，stdout=PIPE时若不及时读取，子进程可能因管道满而挂起（尤其输出量大时） - 想捕获命令失败但又不想抛异常？用
run(……, check=False)，然后检查result.returncode
如何正确传参避免 shell 注入和空格截断
直接拼接字符串传给 run("ls -l /home/user") 看似简单，实则危险：路径含空格、特殊字符（如 $HOME、*）时行为不可控，且易被注入恶意命令。
唯一可靠方式是把命令拆成列表：["ls", "-l", "/home/user with space"]。此时 Python 绕过 shell 解析，参数原样传递给目标程序。
立即学习“Python 免费学习笔记（深入）”；
- 绝对不要用
shell=True处理用户输入（比如 web 表单提交的文件名） - 如果必须用
shell=True（例如需要管道|或通配符展开），确保所有变量都经shlex.quote()处理，如f"grep {shlex.quote(pattern)} file.txt" - Windows 下
shell=True默认调用cmd.exe，行为与 Linux 的sh不同（如重定向语法、内置命令）
实时读取 stdout/stderr 的坑与解法
想边运行边打印日志？别直接用 run(……, stdout=PIPE).stdout.read() —— 这会等进程结束才返回，失去“实时”意义；也别在 Popen 中用 readline() 却忽略换行符或缓冲区大小。
关键点在于：子进程输出是否带行缓冲？Python 的 PIPE 是否被正确设置为非阻塞或逐行读取？
- 子进程本身可能缓冲输出（如 Python 脚本默认行缓冲只在 tty 下生效，
python -u强制无缓冲） - 用
Popen时，推荐stdout=PIPE, stderr=STDOUT, bufsize=1, universal_newlines=True，再配合for line in iter(proc.stdout.readline, ""): - 避免
proc.stdout.read(1)这类单 字节 读取——性能差且容易卡在 EOF 边界 - 如果只是转发日志到控制台，最简方案是不设
stdout=PIPE，让子进程直接继承父进程的sys.stdout
timeout 机制失效的常见原因
subprocess.run(……, timeout=5) 看起来能强制终止超时进程，但实际中常发现进程还在后台跑着——这是因为 timeout 只杀主进程，不递归清理其子进程（如 ping -c 10 启动的 sh + ping 树）。
Linux/macOS 上可用 start_new_session=True 让子进程独立成新会话，再配合 killpg 彻底终结；Windows 则需 creationflags=subprocess.CREATE_NEW_PROCESS_GROUP。
- 没加
start_new_session=True时，timeout触发后只 kill 主进程，子进程变成孤儿继续运行 -
timeout异常是subprocess.TimeoutExpired，不是TimeoutError，捕获时别写错 - 某些程序（如
vim、less）收到SIGTERM也不退出，需改用SIGKILL，但run()不支持自定义信号，此时必须降级用Popen+ 手动send_signal()
子进程的边界比想象中模糊：信号传播、资源继承、会话归属，这些 操作系统 层面的细节一旦忽略，就容易留下僵尸进程或资源泄漏。写完记得用 ps aux | grep your_cmd 或 Process Explorer 验证是否真干净了。
