subprocess.run() 通过 timeout 参数实现超时控制，超时后自动终止子进程并抛出 subprocess.TimeoutExpired 异常；需显式捕获该异常，且为确保子进程彻底终止，建议配合 check=False 和必要时手动清理。
subprocess.run() 怎么加超时控制？
直接用 timeout 参数就行，这是最简单也最推荐的方式。Python 3.3+ 的 subprocess.run() 原生支持超时，超时后自动终止子进程并抛出 subprocess.TimeoutExpired 异常。
注意：不是所有系统都保证子进程被彻底杀死（尤其 Windows 下某些后台进程可能残留），所以必须配合 kill=True 或手动清理。
-
timeout=5表示最多等 5 秒，超时就中断 - 必须显式捕获
subprocess.TimeoutExpired，否则程序会崩 - 默认情况下，超时只中断父进程等待，子进程可能还在跑——要避免假死，得确保它真被杀掉
import subprocess
try:
result = subprocess.run(['sleep', '10'], timeout=3)
except subprocess.TimeoutExpired as e:
print(f"命令超时：{e.cmd}，已终止")
为什么 subprocess.Popen().wait() 加 timeout 还会假死？
因为 Popen.wait(timeout=...) 只是让父进程暂停等待，不主动发信号终止子进程。如果子进程忽略 SIGTERM（比如用 sleep 在 Linux 下可被 kill，但某些 C 程序屏蔽了信号），或者卡在不可中断的系统调用里（如 read() 等待网络响应），wait() 超时返回后，子进程仍在后台运行——这就是“假死”的根源。
-
Popen.poll()返回None不代表进程还活着，只代表没结束；得结合psutil或os.kill(pid, 0)才能确认是否真存活 - Linux 下建议用
preexec_fn=os.setsid创建新会话，后续可用os.killpg()杀整个进程组，防子进程 fork 出孤儿进程 - Windows 没有进程组概念，得用
taskkill /PID {pid} /T /F强杀，或依赖subprocess.run(..., timeout=...)内置逻辑
怎么确保子进程连带子子孙孙都被杀干净？
关键在启动时隔离进程组，再统一销毁。Linux/macOS 推荐用 start_new_session=True（即旧版 preexec_fn=os.setsid），这样 terminate() 或 kill() 能顺带干掉所有后代进程。
librosa 是一个用于音频和音乐分析的 Python 库。它提供了特征提取、频谱分析、节拍跟踪、起始检测和音频可视化的工具，基于 NumPy 和 SciPy 构建，用于科学音频计算。
立即学习“Python免费学习笔记（深入）”；
- 不要只调
proc.terminate()就完事——它只发SIGTERM，有些程序不响应 - 超时后先
proc.terminate()，等 1 秒再proc.kill()强杀，这是稳妥组合 - 若需跨平台且精确控制，用
psutil：启动时记录proc.pid，超时后调用psutil.Process(proc.pid).children(recursive=True)获取全部子进程再逐个杀
import subprocess
import time
proc = subprocess.Popen(['sh', '-c', 'sleep 5 & sleep 10'])
try:
proc.wait(timeout=2)
except subprocess.TimeoutExpired:
proc.terminate()
try:
proc.wait(timeout=1)
except subprocess.TimeoutExpired:
proc.kill()
subprocess 超时和信号处理在不同 Python 版本有啥差异？
Python 3.7+ 对 timeout 的实现更健壮：内部使用 threading.Timer + os.kill 组合，基本能覆盖绝大多数假死场景；3.6 及以前版本在某些嵌入式或容器环境里，timeout 可能失效（比如 glibc 升级后信号处理异常）。
- 3.3–3.6：超时后子进程可能残留，必须手动检查
proc.poll()并补杀 - 3.7+：默认启用
kill行为（见subprocess._posixsubprocess），但仍建议显式调用kill()避免意外 - PyPy 和某些定制 Python 构建（如 Alpine 上的 musl libc）中，
timeout可能完全不触发SIGKILL，此时只能退回到轮询 +os.kill方案
真正难搞的是那种绑死在阻塞 I/O 上、又屏蔽了所有信号的 C 工具——这时候超时只是“父进程放弃等”，子进程本身还得靠操作系统级手段（如 cgroup 限制、容器 runtime 强制回收）来兜底。
