signal.alarm仅在主线程有效，子线程无法设置或响应；替代方案包括threading.timer、asyncio.timeout及对象原生timeout参数，跨平台应避免使用。
signal.alarm 只作用于主线程，子线程无法触发或响应
Linux/Unix 的 alarm 是基于进程的信号机制，底层调用 setitimer 设置的是**整个进程**的实时定时器，但信号（如 SIGALRM）默认只会被**主线程**接收和处理。Python 的 signal 模块本身不支持在非主线程中注册信号处理器——调用 signal.signal 在子线程里会直接抛出 ValueError: signal only works in main thread。
这意味着：即使你在主线程设了 signal.alarm(5)，只要当前执行流在子线程里（比如 threading.Thread 的 run() 方法中），超时也不会中断它；而如果你试图在子线程里重新设 alarm 或捕获 SIGALRM，会直接失败。
替代方案：用 threading.Timer 或 asyncio.timeout 代替
想给一段代码加超时，别碰 signal.alarm，尤其在线程环境里。更可靠、更 Pythonic 的做法是：
- 单次阻塞操作（如
socket.recv、queue.get）：直接用对象自身的timeout参数，比如sock.settimeout(5)或q.get(timeout=5) - 通用同步代码块：用
threading.Timer启动一个倒计时线程，在超时时设置标志位，主逻辑定期检查该标志（注意加锁或用threading.Event） - 异步场景（Python 3.11+）：优先用
asyncio.timeout上下文管理器，它天然支持协程挂起与恢复，不受线程限制
示例（用 Event 实现简单超时协作）：
立即学习“Python免费学习笔记（深入）”；
import threading import time <p>done = threading.Event() timeout_occurred = False</p><p>def worker(): global timeout_occurred if not done.wait(5): # 等待最多 5 秒 timeout_occurred = True return</p><h1>正常逻辑继续...</h1><p>t = threading.Thread(target=worker) t.start() time.sleep(6) # 模拟耗时操作 done.set() # 标记完成（若未超时）
为什么 multiprocessing.Process 里 signal.alarm 有时“看起来有效”
因为每个子进程有独立的信号状态和时钟，signal.alarm 在 fork 出的子进程中可以正常工作——但这不是“多线程有效”，而是“换成了多进程”。常见误区是把 multiprocessing 和 threading 混用，误以为开了个 Process 就能救活线程里的 alarm。
要注意：
- 子进程无法共享主线程的 signal handler，必须在子进程内重新调用
signal.signal - fork 时间点影响 alarm 计时：父进程已设的 alarm 不会继承到子进程（POSIX 规定）
- 进程间通信开销大，为超时这种轻量需求启动进程，得不偿失
容易忽略的兼容性坑：Windows 完全不支持 signal.alarm
signal.alarm 在 Windows 上直接抛出 NotImplementedError，连 import 都没问题，但一调就崩。很多开发者只在 Linux 测试，上线后在 CI 或某些容器环境（比如基于 Windows Server 的 Docker）突然失败。
如果你的代码需要跨平台，或者部署目标不确定：
- 彻底放弃
signal.alarm，改用纯 Python 超时方案（如上面提到的threading.Event+ 轮询，或concurrent.futures.wait） - 用第三方库如
timeout-decorator，它内部做了平台判断，但要注意其基于线程的实现仍有 GIL 和精度限制 - 别依赖
os.kill(os.getpid(), signal.SIGALRM)手动发信号——这在 Windows 无效，且在多线程里可能发错线程
真正麻烦的从来不是“怎么设超时”，而是“怎么确保它在任意线程、任意平台、任意阻塞类型下都按预期中断”。alarm 在这里只是个幻觉。
