subprocess超时后默认只终止主进程，子进程会成为孤儿；必须使用start_new_session=True（Windows自动映射为CREATE_NEW_PROCESS_GROUP）创建独立进程组，再调用proc.terminate()（Py3.7+）或os.killpg()统一终止整个进程树。
subprocess 超时后默认只杀主进程，子进程会变成孤儿
调用 subprocess.run() 或 subprocess.Popen.wait(timeout=...) 时，超时触发的 subprocess.TimeoutExpired 异常只会终止主进程（即你启动的那个可执行文件），但该进程 fork 出的子进程、启动的后台服务、shell 启动的管道链（如 cmd1 | cmd2 &）等通常不受影响。Windows 和 Linux 下都存在这个问题，尤其在调用 shell 脚本、Java 应用或带守护进程行为的程序时，残留进程很常见。
必须显式创建新进程组，再用 os.killpg 或 process.kill() 配合 start_new_session=True
关键不是“怎么杀”，而是“怎么让所有后代进程能被一次性定位并终止”。Linux/macOS 下靠进程组（process group），Windows 下从 Python 3.7+ 开始通过 creationflags=subprocess.CREATE_NEW_PROCESS_GROUP 模拟类似语义：
- Linux/macOS：传
start_new_session=True→ 自动调用setsid()，新进程及其所有后代都在独立 session + pgid 中 - Windows：传
creationflags=subprocess.CREATE_NEW_PROCESS_GROUP→ 创建新进程组，支持os.killpg()（需配合True的sid参数）或直接调用process.terminate()（Python 3.7+ 自动递归终止整个组） - 跨平台稳妥写法：统一用
start_new_session=True（Windows 上它会自动映射为CREATE_NEW_PROCESS_GROUP）
示例：
import subprocess import signal import systry: proc = subprocess.Popen( ["sh", "-c", "sleep 10; echo done"], start_new_session=True, # ← 关键：隔离进程组 stdout=subprocess.PIPE, stderr=subprocess.STDOUT ) proc.communicate(timeout=2) except subprocess.TimeoutExpired: if sys.platform == "win32": proc.terminate() # Python 3.7+ 自动终止整个进程组 else: import os os.killpg(os.getpgid(proc.pid), signal.SIGTERM) proc.wait() # 等待彻底退出
不加 start_new_session=True 就算用 os.killpg 也大概率失败
常见错误是直接对 proc.pid 调用 os.killpg，但此时 proc.pid 所在的进程组往往包含你的 Python 主进程，强行发信号可能 kill 掉自己；更糟的是，如果目标命令本身没新建 session（比如直接跑 ping），它的子进程可能分散在不同 pgid 中，killpg 根本覆盖不到。
- 验证是否生效：Linux 下可用
ps -o pid,ppid,pgid,sid,comm观察目标进程及其子进程的pgid是否一致 - Windows 下没有原生 pgid 概念，但
tasklist /fi "sessionid eq 0"可辅助查看进程树结构 - Shell 脚本中若用了
&、(...)&或nohup，仍需确保最外层Popen启用了start_new_session=True，否则后台任务会逃逸
Python 版本和平台细节决定终止方式是否可靠
Python 3.7 是分水岭：之前版本在 Windows 上 process.terminate() 只杀主进程；3.7+ 才真正支持组终止。Linux 下虽早有 os.killpg，但必须配 start_new_session=True 才安全。
- Python ctypes 调用
GenerateConsoleCtrlEvent+CTRL_C_EVENT，或改用psutil库遍历子进程手动 kill - 避免用
signal.CTRL_C_EVENT发送 Ctrl+C：很多非控制台程序不响应，且无法保证子进程收到 - 如果目标程序是 Java/Node.js 等运行时，它们内部的线程模型可能导致部分工作线程残留，这时仅靠进程级终止不够，需程序自身支持优雅关闭信号（如监听
SIGTERM）
实际中最容易被忽略的，是忘记检查 start_new_session=True 是否真的生效——尤其当命令经过 shell 解析（shell=True）时，某些 shell 实现可能绕过 session 创建，建议始终搭配 shell=False 使用，或在 shell 命令里显式加 setsid（Linux）或 start /b（Windows）。
