用异常代替直接清理可将信号处理交还主执行流，避免中断上下文中的不安全操作；核心是注册信号处理器抛出ShutdownRequested异常，在try/except中统一清理，finally或with确保资源释放。
捕获 SIGTERM 后不直接退出，而是抛出一个自定义异常来触发 try/except/finally 或上下文管理器的清理逻辑，是一种轻量、可复用且与 Python 异常流天然契合的“优雅退出”实践。它避免了在信号处理器中写大量业务代码，也绕开了多线程/异步环境下信号处理的并发风险。
为什么用异常代替直接清理？
信号处理器（signal.signal 回调）运行在中断上下文，不是常规执行流——它可能打断任意正在运行的代码，包括 print、logging、锁操作甚至 GC。在其中做文件关闭、数据库提交或网络调用，既不安全也不可控。而抛出异常，是把控制权交还给主执行路径，在已知、受控的位置（如主循环顶部、请求处理外层）统一响应退出请求。
核心实现：注册信号 + 抛异常 + 捕获闭环
- 定义一个轻量异常类，例如
class ShutdownRequested(Exception): pass - 在主线程中注册信号处理器，仅做一件事：
raise ShutdownRequested() - 将主业务逻辑包裹在
try...except ShutdownRequested:中，except块内专注资源释放（关闭连接、保存状态、等待子任务等） - 确保所有关键资源都由
finally块或with上下文管理器兜底，即使异常未被捕获也能释放
典型结构示例（同步服务）
以下是一个带日志、连接池和主循环的简化模板：
import signal
import time
<p>class ShutdownRequested(Exception):
pass</p><p>def handle_shutdown(signum, frame):
raise ShutdownRequested()</p><p>signal.signal(signal.SIGTERM, handle_shutdown)
signal.signal(signal.SIGINT, handle_shutdown)</p><h1>模拟资源：数据库连接池、文件句柄</h1><p>db_pool = ["conn1", "conn2"]
log_file = open("app.log", "a")</p><p>try:
print("服务启动，按 Ctrl+C 或 kill 发送 SIGTERM")
while True:</p><h1>模拟处理请求</h1><pre class="brush:php;toolbar:false;"> time.sleep(1)
print("working...")except ShutdownRequested: print("收到退出信号，开始清理...")
有序释放：先停新任务，再等进行中任务，最后关资源
if db_pool:
print(f"关闭 {len(db_pool)} 个数据库连接")
db_pool.clear()
log_file.write("Service stopped gracefully.\n")
log_file.flush()finally: log_file.close() print("资源已释放，进程退出")
注意事项与边界情况
- 不能在 except 块里再 raise ShutdownRequested：会导致无限循环；若需重试或延迟退出，改用标志位 + 主循环检查
-
多线程环境慎用全局异常：主线程抛异常不影响子线程；子线程应监听共享
threading.Event，而非依赖异常传播 -
asyncio 不适用此模式：异步事件循环无法被普通异常中断；应使用
loop.stop()或 lifespan 协议，配合asyncio.create_task()执行清理协程 - SIGKILL（kill -9）无法捕获：该信号永远绕过用户代码，任何优雅机制都对其无效
