signal.alarm只能在主线程调用，因为CPython将信号统一交由主线程处理，子线程调用无效；POSIX信号模型不支持线程粒度的SIGALRM注册，且Windows根本不提供SIGALRM。
signal.alarm 为什么只能在主线程调用
因为 Python 的 signal 模块底层完全依赖操作系统信号机制，而 CPython 解释器强制将所有信号的捕获和分发统一交给主线程处理。子线程调用 signal.alarm() 或 signal.signal() 不会报错，但信号永远不会送达该线程——它只会被主线程接收或由内核按默认行为处置（比如直接终止进程）。
你在子线程里调用 alarm 却没反应？这是正常现象
常见错误场景包括：
- 用
threading.Thread启动任务，在线程函数里设signal.alarm(2)，结果超时没触发、函数照常卡死 - 使用
func_timeout等装饰器包装子线程中的函数，实际内部仍走signal.alarm，最终抛ValueError: signal only works in main thread - 多线程服务中试图给每个请求单独设超时，却发现只有第一个线程生效，其余全忽略
根本原因不是代码写错了，而是 POSIX 信号模型本身就不支持“每个线程独立注册 SIGALRM 处理器”。Linux 手册明确指出：signal() 在多线程进程中的行为是未定义的；实际实现中，glibc 把信号递送给任意一个未阻塞该信号的线程，CPython 则选择全部路由到主线程。
想在子线程里做超时？别碰 signal.alarm
替代方案必须绕开信号机制：
立即学习“Python免费学习笔记（深入）”；
- 用
concurrent.futures.ProcessPoolExecutor：启动子进程执行目标函数，主进程用future.result(timeout=...)控制等待时间，超时后子进程被强制终止 —— 全平台可靠，但有进程开销 - 用
threading.Event+ 协作式检查：函数内部定期调用event.is_set()，主线程超时后置位 event；缺点是无法中断 CPU 密集型循环，必须函数主动配合 - 对 I/O 操作，优先用原生 timeout 参数：比如
requests.get(..., timeout=5)、socket.recv(..., timeout=5)，它们不依赖 signal，天然支持子线程
注意：subprocess.run(..., timeout=...) 是特例 —— 它由父进程直接管理子进程生命周期，与 Python 的 signal 无关，所以在任何线程里都能安全使用。
Windows 下 signal.alarm 根本不可用
这不是实现问题，是系统限制：signal.alarm 依赖 SIGALRM，而 Windows 没有这个信号。调用直接抛 NotImplementedError。所以哪怕你只跑在主线程，只要目标环境可能含 Windows，就必须放弃 alarm 方案。
真正跨平台、能杀掉死循环的唯一办法，是换进程 —— ProcessPoolExecutor 或手动 multiprocessing.Process。其他所有基于线程+信号或纯线程协作的方案，都存在无法强制中断的风险。
