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") 日志，不一定真能打出来。
微信小程序公众号SaaS管理系统是一款完全开源的微信第三方管理系统，为中小企业提供最佳的小程序集中管理解决方案。可实现小程序的快速免审核注册（免300元审核费），可批量发布小程序模板，同步升级版本等功能。基础版本提供商城和扫码点餐两种小程序模板。商户端可以实现小程序页面模块化设计和自动生成小程序源代码并直接发布。
