本文深入剖析了在Python中限制函数运行时间的三种核心策略：针对Unix/Linux/macOS平台的轻量级`signal.alarm`方案（仅适用于主线程纯计算函数，Windows不支持）；跨平台通用的`ProcessPoolExecutor`强制终止子进程方案（可真正杀掉死循环或不可中断阻塞，但有启动开销和序列化限制）；以及调用外部命令时最稳妥的`subprocess.run(timeout=...)`原生支持方案（自动处理信号与进程树清理）。文章不仅给出简洁可用的代码示例，更关键地揭示了各方法的适用边界、典型陷阱（如信号冲突、GIL导致线程超时失效、孤儿进程残留）及实战建议（如必设`start_new_session=True`、及时`alarm(0)`清零、区分不同`TimeoutError`类型），帮助开发者避开高发雷区，构建真正可靠、可移植的超时控制机制。

用 signal.alarm 在 Unix/Linux/macOS 上设超时最轻量

Linux 和 macOS 支持 signal.SIGALRM，能在指定秒数后触发中断。这是开销最小的方案，适合纯计算型函数（不涉及 I/O 阻塞）。

注意：signal.alarm 不能在子线程中使用，且 Windows 完全不支持 —— 如果脚本要跨平台，这条路直接排除。

• 必须在主线程调用，且不能和 threading 混用
• alarm 只对当前进程有效，无法限制子进程（如 subprocess.Popen）
• 若函数内有阻塞调用（如 time.sleep、input），信号可能被延迟送达

import signal
def timeout_handler(signum, frame):
raise TimeoutError("Function timed out")
def risky_computation():
signal.signal(signal.SIGALRM, timeout_handler)
signal.alarm(3)  # 3 秒后触发
try:
这里放耗时逻辑
    time.sleep(5)
finally:
    signal.alarm(0)  # 关闭 alarm

用 concurrent.futures.ProcessPoolExecutor 跨平台保命

需要真正杀掉卡死进程（比如 C 扩展死循环、无限递归、或调用了不可中断的系统调用），唯一可靠方式是换进程。Windows 和 Linux 都支持 ProcessPoolExecutor，它能强制终止子进程。

代价是启动开销大、无法共享内存、参数/返回值必须可序列化（pickle 兼容）。

• 超时由 executor.submit(...).result(timeout=...) 控制，超时后自动调用 process.terminate()
• 不要用 ThreadPoolExecutor —— 线程无法被强制杀死，timeout 只是抛异常，原线程仍在后台跑
• 子进程崩溃时，result() 会抛 concurrent.futures.TimeoutError，不是内置 TimeoutError

from concurrent.futures import ProcessPoolExecutor
import time
def long_task():
time.sleep(10)
return "done"
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
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 配置，再配合日志和重试机制兜底。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~