signal.signal() 默认仅主线程有效，子线程注册无效；阻塞调用（如 time.sleep、queue.get）可能延迟或丢弃 SIGINT；可靠中断应使用 threading.Event 轮询或 timeout 接口。
signal.signal() 为什么收不到 Ctrl+C？
Python 的 signal.signal() 默认只在主线程生效，子线程里调用它没用，而且即使主线程注册了 SIGINT，如果当前正阻塞在某些 C 扩展调用（比如 time.sleep()、queue.get()、某些数据库驱动的等待）中，信号也可能被延迟甚至丢弃。
- 主线程外注册 signal.signal() 是无效的，别白费劲
- 不要依赖“信号一定能打断阻塞”，尤其在使用 requests、psycopg2 或 cv2.waitKey() 这类底层阻塞调用时
- 真正可靠的中断方式是：用 threading.Event 配合轮询，或改用支持 timeout 的接口（如 queue.get(timeout=1)）
- 如果必须用信号，确保在主线程注册，并且避免长时间无检查的阻塞调用
用 signal.pause() 还是 while True + time.sleep()？signal.pause() 看起来简洁，但它会让进程完全挂起、只响应信号，无法做任何周期性检查（比如健康检查、心跳、状态更新），实际生产中几乎不用。
- signal.pause() 适合写一次性监听脚本，比如等某个信号就退出，不干别的
- 大多数服务场景该用带超时的循环：while not exit_event.is_set(): time.sleep(0.1)
- Python 3.3+ 的 signal.sigwait() 更可控，但仅支持 Linux/macOS，且要求信号被设为阻塞态（signal.pthread_sigmask(signal.SIG_BLOCK, [signal.SIGINT])）
- Windows 下 sigwait() 不可用，别写跨平台代码时硬套
多线程里怎么安全地处理信号？ 信号本质是进程级的，没法发给指定线程；Python 的信号处理器总是在主线程执行。如果你在子线程里修改了全局变量、释放了资源，而信号处理器也去操作同一份数据，大概率出竞态。
- 不要在信号处理器里做复杂操作：别调用 print()（可能死锁）、别操作 logging（非线程安全）、别修改共享对象
- 推荐模式：信号处理器只设置一个 threading.Event，主逻辑轮询它
- 别在信号处理器里调用 sys.exit()，它会跳过 finally 和 atexit 注册函数
- 如果用了 concurrent.futures，记得在 shutdown 前先 cancel 正在运行的 future，否则线程池可能卡住
signal.setitimer() 定时触发不稳定？signal.setitimer() 基于系统 setitimer(2)，精度受系统调度和 Python GIL 影响，实际触发时间常比设定值晚几十毫秒，且不能保证每次都在同一个线程上下文执行。
- 它不适合需要亚秒级精度的任务（比如音频采样、实时控制）
- 在容器环境或 CPU 负载高时，定时器可能严重漂移甚至丢失一次触发
- 替代方案更可靠：用 threading.Timer（单次）或 asyncio.call_later()（异步场景）
- 如果坚持用 setitimer()，务必配合 signal.siginterrupt(False) 防止系统调用被中断后不重试
信号处理最麻烦的不是注册，而是「你以为它发生了，其实没有」——尤其是跨平台、混用 C 扩展、或者信号和线程一起上时。留个 print("got SIGINT") 日志，不一定真能打出来。
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
