SystemExit 不被 except Exception: 捕获是设计使然，因其与 Exception 同为 BaseException 的直系子类；它属于程序控制信号而非错误，仅应在嵌入式 REPL、测试断言或高层 API 封装等明确场景下捕获。
SystemExit 和其他继承自 BaseException 的异常（如 KeyboardInterrupt、GeneratorExit）默认不被普通 except Exception: 捕获，这是设计使然，不是疏漏。
这是因为 Exception 类本身是 BaseException 的子类，而 SystemExit 是 BaseException 的直系子类，和 Exception 并列。所以：
except Exception: 只捕获 Exception 及其所有子类（比如 ValueError、ZeroDivisionError），但不会捕获 SystemExit、KeyboardInterrupt 或 SystemExit
这正是为什么你在写脚本时加了 except Exception: 却发现 Ctrl+C 还是能中断程序、sys.exit() 依然能退出——它们根本没进这个 except 分支。
什么时候该捕获 SystemExit？
极少需要，仅限以下明确场景：
- 你正在写一个嵌入式 Python 解释器外壳（比如 REPL 工具），希望把
sys.exit()转为静默返回，而不是终止整个进程 - 你在测试中想断言某段代码是否调用了
sys.exit()，需用unittest.mock.patch('sys.exit')或直接捕获SystemExit - 你封装了一个高层 API，承诺“绝不退出进程”，此时需兜底拦截
SystemExit并转为抛出RuntimeError或日志告警
示例：
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
try:
some_untrusted_code()
except SystemExit as e:
# 不让 sys.exit() 终止进程，改用日志+返回码
logger.warning("Code tried to exit with code %s", e.code)
raise RuntimeError("Exit attempt blocked") from e
except Exception:
# 处理业务异常
handle_error()
except BaseException: 是不是万能解？
不是，而且通常不该这么写。原因：
-
BaseException包含KeyboardInterrupt和SystemExit，也包含GeneratorExit—— 捕获它会让Ctrl+C失效，用户无法中止卡死的程序 -
MemoryError、RecursionError等严重错误也属于BaseException，强行捕获后继续执行可能引发不可预测状态 - Python 官方文档明确建议：只在最外层异常处理器（比如主循环顶部）或调试工具中才考虑捕获
BaseException，且必须重新抛出或显式终止
典型反例：
while True:
try:
do_work()
except BaseException: # ❌ 危险：Ctrl+C 无效，内存爆了也不停
continue # 错误地忽略一切
为什么 sys.exit() 不抛 Exception？
因为它的语义不是“出错了”，而是“我决定结束当前流程”。Python 把这类控制流操作和错误区分开：
-
Exception表示**意外状况**，需要处理或传播 -
SystemExit、KeyboardInterrupt属于**程序控制信号**，设计上就该绕过常规错误处理路径 - 如果
sys.exit()抛的是Exception，那所有except Exception:都会意外吞掉退出请求，导致脚本无法正常终止
真正容易被忽略的点是：很多教程和代码模板习惯性写 except Exception: 作为“兜底”，却没意识到它对 SystemExit 和 KeyboardInterrupt 完全无效——这不是 bug，是 Python 异常层级的刻意安排。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
