应优先使用 concurrent.futures.TimeoutError 捕获超时，因其提供真正可中断的执行边界；signal.alarm() 仅限 Unix 且不兼容多线程；asyncio.wait_for() 更适合异步任务；第三方装饰器库存在兼容与稳定性问题。
用 concurrent.futures.TimeoutError 捕获超时更可靠
直接用 time.time() 手动计时再 break 或 return，容易漏掉正在运行的子进程或线程。Python 标准库的 concurrent.futures 提供了真正可中断的执行边界。
-
ThreadPoolExecutor和ProcessPoolExecutor的submit().result(timeout=...)会抛出concurrent.futures.TimeoutError，不是普通Exception，必须显式捕获 - 超时后，任务在后台仍可能继续运行（尤其
ProcessPoolExecutor），需配合executor.shutdown(wait=False)避免主程序卡住 - Windows 下
ProcessPoolExecutor对超时响应略慢，建议优先用ThreadPoolExecutor处理 I/O 类任务
from concurrent.futures import ThreadPoolExecutor, TimeoutError
with ThreadPoolExecutor() as executor:
future = executor.submit(time_consuming_func, arg)
try:
result = future.result(timeout=5)
except TimeoutError:
print("任务超时，已放弃等待")
signal.alarm() 只在 Unix 系统生效，别在 Windows 上试
想用操作系统级信号强制中断？signal.alarm() 确实能触发 signal.SIGALRM，但它只在 Linux/macOS 有效，Windows 完全不支持——连 import signal 都能过，但调用 alarm() 会直接报 OSError。
- 仅适用于单线程、纯 Python 函数（C 扩展或阻塞系统调用可能不响应信号）
- 不能和
threading混用：信号只发给主线程，子线程收不到 - 使用前必须确保当前线程是主线程，且未被
settrace或调试器干扰
import signal
def timeout_handler(signum, frame):
raise TimeoutError("信号超时")
signal.signal(signal.SIGALRM, timeout_handler)
signal.alarm(3) # 3秒后触发
try:
result = risky_io_call()
signal.alarm(0) # 取消定时器
except TimeoutError:
pass异步任务用 asyncio.wait_for()，别混用 loop.run_in_executor + 超时
如果你已经用了 asyncio，就别把同步函数丢进 run_in_executor 再套一层超时逻辑——这既难调试，又容易让事件循环卡死。原生 asyncio.wait_for() 是为协程设计的，能真正取消挂起的任务。
-
wait_for()的timeout参数单位是秒（支持浮点数），超时后抛出asyncio.TimeoutError - 被等待的协程如果没做取消处理（比如没检查
asyncio.current_task().cancelled()），可能继续跑完，只是结果被丢弃 - 避免对同一个协程多次
wait_for：协程只能被 await 一次，重复调用会报InvalidStateError
import asyncio
try:
result = await asyncio.wait_for(fetch_data(), timeout=10.0)
except asyncio.TimeoutError:
print("网络请求超时")第三方库 pytimedout 或 func-timeout 封装简单，但有隐蔽兼容问题
这类装饰器库看着省事，但底层往往依赖 signal 或 threading.Timer，实际表现不稳定：
立即学习“Python免费学习笔记（深入）”；
-
func-timeout在 Python 3.11+ 中因sys.settrace行为变更，可能导致超时失效 -
pytimedout默认用子进程隔离，但 Windows 创建进程开销大，且无法传递闭包变量 - 所有装饰器方案都难以处理 C 扩展里的阻塞调用（如某些数据库驱动的
.execute()）
真要图快，不如自己封装一个轻量版：concurrent.futures + 显式 future.cancel() + atexit 清理，比黑盒库更可控。
超时从来不是加个参数就完事的事——关键是看任务在哪卡住：CPU 密集？I/O 阻塞？还是外部服务无响应？选错机制，超时就只是个摆设。
