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 
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，它能强制终止子进程。
立即学习“Python免费学习笔记（深入）”；
代价是启动开销大、无法共享内存、参数/返回值必须可序列化（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 配置，再配合日志和重试机制兜底。