Python服务优雅退出需捕获SIGINT/SIGTERM信号并注册处理函数，多线程用Event通知+join等待，asyncio须按shutdown_asyncgens→run_until_complete→close顺序执行，WSGI/ASGI服务器需正确配置超时与生命周期事件。
Python 服务如何捕获 Ctrl+C 和系统信号
Python 服务要“优雅退出”，第一步是能及时感知退出信号。默认情况下，Ctrl+C 发送 SIGINT，Linux 服务常被 systemd 或 kill 发送 SIGTERM。不主动监听这些信号，进程会立即终止，来不及清理资源。
用 signal.signal() 注册处理函数是最直接的方式：
import signal
import sys
<p>def graceful_exit(signum, frame):
print(f"Received signal {signum}, shutting down...")</p><h1>这里放清理逻辑：关闭连接、保存状态、等待任务完成等</h1><pre class="brush:php;toolbar:false;">sys.exit(0)signal.signal(signal.SIGINT, graceful_exit) signal.signal(signal.SIGTERM, graceful_exit)
-
SIGINT和SIGTERM都需显式注册；只处理一个会导致另一种方式强制 kill - 避免在信号处理器中做耗时操作（如网络请求、文件写入），它运行在中断上下文，可能被再次中断
- 某些异步框架（如
asyncio）有自己的信号管理机制，直接覆盖可能冲突，应优先用其原生方式（如asyncio.loop.shutdown_asyncgens()）
多线程服务中如何安全等待子线程结束
主线程收到退出信号后，若直接退出，正在运行的 threading.Thread（尤其是 daemon=False）会被强制终止，导致数据丢失或资源泄漏。
关键不是“杀死线程”，而是“通知+等待”：
立即学习“Python免费学习笔记（深入）”；
- 用
threading.Event作为全局退出标志，各工作线程定期检查exit_event.is_set() - 主线程调用
exit_event.set()后，再对每个非守护线程调用join(timeout=5)，避免无限等待 - 不要依赖
threading.Thread.daemon = True实现“优雅”——守护线程会在主线程退出时被强制结束，无机会清理
示例片段：
exit_event = threading.Event()
<p>def worker():
while not exit_event.is_set():</p><h1>执行任务</h1><pre class="brush:php;toolbar:false;"> time.sleep(1)
# 清理逻辑，如关闭数据库连接
print("Worker cleaned up")t = threading.Thread(target=worker) t.start()
收到信号后：
exit_event.set() t.join(timeout=3) # 最多等 3 秒
使用 asyncio 时 shutdown_asyncgens 和 run_until_complete 的顺序
在 asyncio 服务中，仅调用 loop.stop() 或直接 sys.exit() 会导致挂起的协程、异步生成器（async generators）被丢弃，__aexit__ 不执行，连接不关闭。
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
正确顺序必须严格遵守：
- 先调用
loop.shutdown_asyncgens()：确保所有异步生成器完成aclose() - 再用
loop.run_until_complete(shutdown_coro())执行自定义的异步清理逻辑（如await pool.close()、await server.wait_closed()） - 最后调用
loop.close()；注意：一旦close()，不能再调用run_until_complete
常见错误是漏掉 shutdown_asyncgens()，导致出现 RuntimeWarning: coroutine 'xxx' was never awaited 或连接泄漏。
WSGI/ASGI 服务器（如 Gunicorn、Uvicorn）的配置要点
生产环境很少裸跑 Python 脚本，更多是通过 Gunicorn（WSGI）或 Uvicorn（ASGI）托管。它们自身已实现信号转发和超时等待，但需正确配置才能触发应用层的优雅退出。
- Gunicorn：设置
--graceful-timeout（默认 30s），表示收到SIGTERM后，主进程等待工作进程完成当前请求的最长时间；同时应用需监听SIGTERM做清理 - Uvicorn：用
--timeout-graceful-shutdown（默认 2s），配合--limit-concurrency控制并发，防止新请求在 shutdown 期间涌入 - 务必禁用
--preload（Gunicorn）或确保on_shutdown事件注册在主进程而非 worker 进程中，否则清理逻辑可能执行多次或不执行
例如 Uvicorn 的 lifespan 协议：
from fastapi import FastAPI
<p>app = FastAPI()</p><p>@app.on_event("startup")
async def startup():
pass</p><p>@app.on_event("shutdown")
async def shutdown():</p><h1>这里会由 Uvicorn 在收到 SIGTERM 后自动调用</h1><pre class="brush:php;toolbar:false;">await cleanup_db_connections()
真正容易被忽略的是：lifespan 事件只在 ASGI 服务器支持该协议时才生效（Uvicorn ≥ 0.13，Hypercorn 支持，Gunicorn 不支持）。用错服务器或版本，on_event("shutdown") 就是摆设。
