signal.alarm是Unix/Linux/macOS上最轻量的超时方案，仅适用于主线程纯计算函数；跨平台需用ProcessPoolExecutor强制终止子进程；调用外部命令应直接使用subprocess.run的timeout参数。
用 signal.alarm 在 Unix/Linux/macOS 上设超时最轻量
Linux 和 macOS 支持 signal.SIGALRM，能在指定秒数后触发中断。这是开销最小的方案，适合纯计算型函数（不涉及 I/O 阻塞）。
注意：signal.alarm 不能在子线程中使用，且 Windows 完全不支持 —— 如果脚本要跨平台，这条路直接排除。
- 必须在主线程调用，且不能和
threading混用 -
alarm只对当前进程有效，无法限制子进程（如subprocess.Popen） - 若函数内有阻塞调用（如
time.sleep、input），信号可能被延迟送达
import signal
<p>def timeout_handler(signum, frame):
raise TimeoutError("Function timed out")</p><p>def risky_computation():
signal.signal(signal.SIGALRM, timeout_handler)
signal.alarm(3) # 3 秒后触发
try:</p><h1>这里放耗时逻辑</h1><pre class="brush:php;toolbar:false;"> time.sleep(5)
finally:
signal.alarm(0) # 关闭 alarm
用 concurrent.futures.ProcessPoolExecutor 跨平台保命
需要真正杀掉卡死进程（比如 C 扩展死循环、无限递归、或调用了不可中断的系统调用），唯一可靠方式是换进程。Windows 和 Linux 都支持 ProcessPoolExecutor，它能强制终止子进程。
立即学习“Python免费学习笔记（深入）”；
代价是启动开销大、无法共享内存、参数/返回值必须可序列化（pickle 兼容）。
- 超时由
executor.submit(...).result(timeout=...)控制，超时后自动调用process.terminate() - 不要用
ThreadPoolExecutor—— 线程无法被强制杀死，timeout只是抛异常，原线程仍在后台跑 - 子进程崩溃时，
result()会抛concurrent.futures.TimeoutError，不是内置TimeoutError
from concurrent.futures import ProcessPoolExecutor
import time
<p>def long_task():
time.sleep(10)
return "done"</p><p>with ProcessPoolExecutor(max_workers=1) as executor:
future = executor.submit(long_task)
try:
result = future.result(timeout=3)
except TimeoutError: # 注意：这里是 concurrent.futures.TimeoutError
print("Killed by timeout")
用 subprocess.run 控制外部命令超时最稳妥
如果你其实是在调用外部程序（如 ffmpeg、curl、自写 CLI 工具），别自己封装超时逻辑 —— 直接用 subprocess.run 的 timeout 参数，它底层调用 kill（Unix）或 TerminateProcess（Windows），行为一致且可靠。
这个方法不适用于纯 Python 函数，但对 shell 命令、二进制工具、甚至 python script.py 这类调用，是最推荐的路径。
-
timeout单位是秒（浮点数也行），超时后自动发送SIGTERM（Unix）或终止进程树（Windows） - 务必捕获
subprocess.TimeoutExpired，而不是通用Exception - 如果被杀进程起了子进程（如 bash -c "sleep 10 &"），部分系统下子进程可能残留，加
start_new_session=True可解决
import subprocess
<p>try:
result = subprocess.run(
["sleep", "10"],
timeout=3,
capture_output=True,
text=True,
start_new_session=True
)
except subprocess.TimeoutExpired as e:
print("Command killed after 3s")
别踩这些坑：信号、GIL 和子进程清理
超时控制最容易翻车的地方不在主逻辑，而在边界情况：信号冲突、GIL 锁死、孤儿进程、资源泄漏。
-
signal.alarm和time.sleep在同一线程里可能互相干扰，尤其在反复设置时；用完必须alarm(0)清零 - Python 的 GIL 不影响
ProcessPoolExecutor，但会让ThreadPoolExecutor的 timeout 失效 —— 线程卡在 C 扩展里时，Python 层根本收不到中断 - 用
ProcessPoolExecutor后没等future结束就退出上下文，子进程可能变成僵尸；确保future.done()或显式shutdown(wait=True) - Windows 下
subprocess杀进程有时不彻底，特别是调用了 cmd /c 的场景，start_new_session=True是保险选择
真正难处理的是“不可中断的阻塞”——比如某些数据库驱动的查询、SSL 握手、或硬件级等待。这种时候，没有银弹，只能靠外部进程隔离 + 严格 timeout 配置，再配合日志和重试机制兜底。
