asyncio.run不能直接响应Ctrl+C，因其内部用run_until_complete启动协程且不监听信号，导致KeyboardInterrupt延迟传递；需手动注册SIGINT处理器并确保主协程可取消。
asyncio.run 为什么不能直接响应 Ctrl+C？
因为 asyncio.run 内部默认用 loop.run_until_complete 启动主协程，它不主动监听系统信号；一旦主协程阻塞（比如在 asyncio.sleep 或网络等待中），KeyboardInterrupt 就会被压在事件循环外层，直到下一次 Python 主线程有机会检查中断——这会造成延迟响应甚至“卡住”几秒才退出。
常见错误现象：Ctrl+C 按下后无反应，或要连按两三次才生效；日志里看不到清理逻辑执行。
- 根本原因：信号由主线程接收，但事件循环可能正忙于调度协程，没及时把中断转为取消动作
- 解决思路不是重写
asyncio.run，而是让它启动前就注册好信号处理器，并确保主协程能被安全取消 - 别在
asyncio.run外层套try/except KeyboardInterrupt—— 它捕不到，因为异常根本没抛到那里
如何让 asyncio.run 支持优雅关闭？
核心是两步：提前设置信号处理器 + 让主协程可取消。Python 3.11+ 的 asyncio.run 已支持 shutdown_asyncgens=True 和 shutdown_default_executor=True，但信号处理仍需手动介入。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 用
signal.signal(signal.SIGINT, ...)注册一个回调，在里面调用loop.stop()或触发协程取消 - 主协程必须包装成可被
asyncio.create_task调度的形式，不能直接传一个无限while True协程给asyncio.run - 推荐结构：把业务逻辑写进一个顶层协程（如
main()），再用asyncio.run(main())启动；信号处理器负责取消这个任务
简短示例：
import asyncio
import signal
<p>async def main():
try:
while True:
print("running...")
await asyncio.sleep(1)
except asyncio.CancelledError:
print("cleanup started")
await asyncio.sleep(0.1) # 模拟清理
print("done")
raise</p><p>def handle_sigint(signum, frame):
task = asyncio.current_task()
if task:
task.cancel()</p><p>if <strong>name</strong> == "<strong>main</strong>":
loop = asyncio.new_event_loop()
asyncio.set_event_loop(loop)
loop.add_signal_handler(signal.SIGINT, handle_sigint)
try:
loop.run_until_complete(main())
finally:
loop.close()
asyncio.run 与手动管理 loop 的取舍
很多人想坚持用 asyncio.run 是因为它自动管理 loop 生命周期、避免重复创建，但它的信号处理是“开箱即黑盒”。真要优雅关机，就得放弃纯 asyncio.run(main()) 写法，改用显式 loop.run_until_complete + add_signal_handler。
关键差异点：
-
asyncio.run在 Python 3.12 中仍不支持add_signal_handler—— 它内部新建的 loop 是私有且不可访问的 - 手动建 loop 更可控，但要注意：不能在已运行 loop 的线程里再调
asyncio.run，否则报RuntimeError: asyncio.run() cannot be called from a running event loop - 如果你用的是 FastAPI/Uvicorn 或其他框架，它们已经接管了信号处理，此时不该自己再注册
SIGINT，否则冲突
清理逻辑为什么常被跳过？
即使信号被捕获、任务被取消，await 后的清理代码仍可能不执行，原因很具体：协程被取消时如果正卡在某个 await 点（比如 await aiofiles.open(...)），而那个底层对象没实现 __aexit__ 的超时或中断响应，就会挂住。
典型场景：
- HTTP 客户端（如
aiohttp.ClientSession）未显式close()，连接池资源泄漏 - 数据库连接（
aiomysql/asyncpg）没调close()，连接不释放 - 使用
async with包裹资源，但主协程被取消太快，导致__aexit__来不及跑完
对策很简单：所有异步资源操作都包在 try/finally 里，或确保 async with 块外还有兜底 await resource.close() 调用。
容易被忽略的一点：asyncio.shield() 会阻止取消传播，如果你在清理阶段用了它，那 cleanup 就真的不会跑了。
