应显式捕获并执行清理后再退出，而非直接终止；需根据是否持有外部资源判断，推荐顶层try/except调用cleanup，信号处理宜用标志位，异步程序须取消所有task并妥善处理异常。
捕获 KeyboardInterrupt 后该不该直接退出
大多数情况下，KeyboardInterrupt（Ctrl+C）是用户主动中止程序的信号，但“直接退出”未必安全——比如正在写文件、发 HTTP 请求、持有数据库连接或子进程时，硬退出可能导致数据损坏或资源泄漏。真正需要的是：在响应中断的同时，完成必要的清理工作。
关键判断点：你的程序是否持有外部资源或处于中间状态？ 如果是，就不能靠 Python 默认行为（抛出异常后终止），而要显式捕获并处理。
try/except KeyboardInterrupt 的正确写法
最基础也最容易出错的方式就是裸捕获：except KeyboardInterrupt: 后直接 sys.exit() 或 break。这忽略了嵌套循环、多层函数调用、以及是否已开始清理的问题。
- 推荐在主流程顶层（如
if __name__ == "__main__":块内）设一个统一入口级try/except - 避免在深层函数里单独捕获——除非你明确知道该层能完整收尾（比如某个独立的 CLI 子命令）
- 捕获后不要立刻退出，先调用清理函数，再决定是否
sys.exit(0)或继续运行
示例：
立即学习“Python免费学习笔记（深入）”；
def cleanup():
print("正在关闭连接...")
# 关闭文件、socket、DB 连接等
<p>if <strong>name</strong> == "<strong>main</strong>":
try:
main_loop() # 可能含 while True
except KeyboardInterrupt:
cleanup()
print("已安全退出")
sys.exit(0)
使用 signal.signal(signal.SIGINT, ...) 的适用场景
当你的程序有长时间阻塞调用（如 time.sleep()、queue.get()、某些 C 扩展的 IO 等），KeyboardInterrupt 可能无法及时触发——因为 Python 的信号处理只在 Python 字节码执行间隙生效。这时需注册信号处理器。
- 仅在确实遇到“Ctrl+C 不响应”时才用，不是默认方案
- 信号处理器中不能做复杂操作（比如调用
print或logging多数线程不安全），推荐只设一个标志位 - 主循环需定期检查该标志，再主动退出
示例：
立即学习“Python免费学习笔记（深入）”；
import signal interrupted = False <p>def signal_handler(sig, frame): global interrupted interrupted = True</p><p>signal.signal(signal.SIGINT, signal_handler)</p><p>while not interrupted: do_work() time.sleep(1) # 避免忙等 cleanup()
协程与异步代码中如何响应 Ctrl+C
在 asyncio 程序里，KeyboardInterrupt 会以 CancelledError 形式传播到当前 task，但默认行为可能只是中断当前协程，而未取消整个 event loop 或清理后台任务。
- 不要在
async def内直接try/except KeyboardInterrupt——它根本不会被捕获 - 应在
asyncio.run()外层捕获，或使用loop.set_exception_handler()拦截CancelledError - 务必调用
asyncio.all_tasks()并cancel()它们，再await asyncio.gather(..., return_exceptions=True)
简单可靠的做法：
try:
asyncio.run(main())
except KeyboardInterrupt:
print("收到中断，正在清理...")
# 此处可手动 cancel tasks（如果 run() 已返回）或依赖 asyncio.run 的默认清理
注意：asyncio.run() 自 Python 3.11 起对 Ctrl+C 的响应更健壮，但仍建议测试你的具体版本和任务结构。
真正容易被忽略的是：清理逻辑本身是否可重入、是否可能再次抛出异常。比如关闭已关闭的 socket、重复调用 atexit 注册函数，或者在清理中又遇到 Ctrl+C。这类边界情况，比“怎么捕获”更值得花时间验证。
