sys.exit() 抛出 SystemExit 异常，继承自 BaseException，无法被 except Exception 捕获；os._exit() 则绕过异常机制直接终止进程，不执行清理。
sys.exit() 触发的 SystemExit 是特殊异常
sys.exit() 本质是主动抛出 SystemExit 异常，不是操作系统信号或进程 kill。它被设计成“可被捕获但默认终止程序”的行为，和 ValueError、KeyError 这类运行时异常在语义上完全不同：前者表示“程序意图结束”，后者表示“计算出错了”。
关键区别在于：SystemExit 继承自 BaseException，而不是 Exception。这意味着：
- 普通
except:或except Exception:块**捕获不到**它 - 必须显式写
except SystemExit:或except BaseException:才能拦截 - 哪怕没被 catch，Python 解释器也会静默处理它，不打印 traceback（除非传了非 0 状态码且未被处理）
os._exit() 根本不走异常机制
os._exit() 完全绕过 Python 的异常系统和清理流程。它直接调用操作系统 _exit() 系统调用，进程立即终止，不做任何 Python 层面的事：
- 不会触发
finally块 - 不会执行
__del__方法 - 不会刷新
print()缓冲区（可能丢失最后一行输出） - 不会抛出任何异常——所以你 无法用 try/except 捕获它
它只适合 fork 后的子进程、或极端场景下需要“硬退出”时使用，日常脚本里基本不该出现。
立即学习“Python免费学习笔记（深入）”；
如何安全捕获并区分退出意图与错误
如果你写的是命令行工具或服务入口，需要在退出前做清理（比如关闭文件、释放锁），又想区分“用户主动退出”和“真出错了”，推荐这样组织：
- 统一用
sys.exit(n)表达退出意图（n=0 表示成功，n≠0 表示失败原因） - 主逻辑包在
try...except BaseException:中，但只对SystemExit做清理后 re-raise - 对
Exception子类做日志记录，再sys.exit(1)统一退出
示例片段：
import sys
<p>def main():
try:</p><h1>你的业务逻辑</h1><pre class="brush:php;toolbar:false;"> if need_exit_gracefully:
sys.exit(0)
except SystemExit as e:
cleanup_resources()
raise # 让 exit 照常生效
except Exception as e:
log_error(e)
sys.exit(1)if name == 'main': main()
别把 exit() / quit() 当正式退出手段
exit() 和 quit() 只是交互式解释器里的便利函数，底层就是调 sys.exit()。它们在生产脚本中应该被禁用：
- 它们不是语言关键字，而是内置函数，可能被覆盖或误删
- 代码审查时容易被当成调试残留
- 某些静态检查工具（如 pylint）会直接报
W0622警告
真正要退出，就明确写 import sys; sys.exit(0)，一眼可知意图，也方便 grep 和自动化分析。
实际部署时最容易忽略的点是：SystemExit 在多线程环境里只终止当前线程，不是整个进程——如果主线程已退出，但后台线程还在跑，程序不会真正结束。这时候得配合 threading.settrace 或显式管理线程生命周期。
