应使用 atexit.register() 而非 try/except 捕获 systemexit，因 sys.exit() 触发后解释器可能跳过外层 except；atexit 确保清理逻辑在任何退出路径下无条件执行，且按逆序调用。
为什么不能用 try/except 捕获 sys.exit() 的常规调用
sys.exit() 本质是抛出 SystemExit 异常，按理说能被 try/except SystemExit: 捕获。但实际中，如果你在主模块顶层写 try: main() except SystemExit: cleanup()，往往清理逻辑不执行——因为 Python 解释器在收到 SystemExit 后会立即开始退出流程，跳过外层 except 块（尤其当异常从 main() 内部抛出、且未被该函数内层捕获时）。更关键的是，atexit 注册的函数总能运行，而手动 try/except 容易漏掉多层调用链中的出口点。
用 atexit.register() 替代手动捕获 SystemExit
真正可靠的方式不是去“捕获”它，而是让清理逻辑在进程终止前**无条件触发**。Python 的 atexit 模块专为此设计：无论程序因 sys.exit()、正常返回、还是接收到 SIGTERM（在支持信号的系统上）而退出，注册的函数都会执行。
- 在程序启动早期就调用
atexit.register(cleanup_func)，越早越好（比如导入后、main()前） -
cleanup_func不应依赖全局状态是否完整；它可能在部分对象已被 gc 或线程已终止时运行 - 避免在
atexit回调里调用os._exit()或再次sys.exit()，会导致未定义行为 - 多个注册函数按**逆序**执行（后注册的先运行），适合做资源释放顺序控制
import atexit
import sys
<p>def cleanup():
print("正在关闭数据库连接...")</p><h1>实际清理逻辑</h1><p>atexit.register(cleanup) # 必须在 sys.exit() 可能发生前注册</p><p>if len(sys.argv) </p><div class="aritcle_card flexRow artxards">
<div class="artcardd flexRow">
<a class="aritcle_card_img" rel="nofollow" href="/xiazai/skill7657" title="python 查询技能"><img
src="https://img.php.cn/upload/skill/000/000/081/179161384046229.jpg" alt="python 查询技能" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
<div class="aritcle_card_info flexColumn">
<a rel="nofollow" href="/xiazai/skill7657" title="python 查询技能" class="overflowclass">python 查询技能</a>
<p class="overflowclass">查询客流数据，输出JSON格式，可直接导入Bitable等可视化工具</p>
</div>
<a rel="nofollow" href="/xiazai/skill7657" title="python 查询技能" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span>
</a>
</div>
</div><h3>哪些场景下 <code>try/except SystemExit</code> 确实有用</h3><p>仅限于你明确控制某段代码的执行边界，并需要在该边界内拦截退出意图、改写行为或补充日志。典型如单元测试、CLI 子命令封装、沙箱环境。</p>
- 测试框架中模拟
sys.exit()并验证退出码：with self.assertRaises(SystemExit) as cm: my_script.main() - CLI 工具中统一处理子命令退出：
try: subcommand.run() except SystemExit as e: log(f"子命令退出: {e.code}"); raise - 注意：必须确保
except块本身不引发新异常，否则atexit仍可能被跳过 - 不要在
except SystemExit中再调用sys.exit()，这属于重复退出，容易掩盖原始退出码
清理函数里最容易被忽略的三件事
atexit 回调看似简单，但实际运行时环境已不稳定。以下三点不处理好，清理就形同虚设：
-
sys.stdout和sys.stderr可能已被关闭，直接print()会抛ValueError；改用os.write(2, b"msg\n")或先检查sys.stderr and not sys.stderr.closed - 线程可能正在运行，但
threading.Thread.join()在退出阶段可能永远阻塞；应设超时，或改用threading.Event配合主逻辑主动通知 - 文件句柄、数据库连接等资源若使用了带 finalizer 的 wrapper（如
contextlib.closing），它们的__exit__不保证被调用；清理函数里要显式.close()
真正难的不是注册清理函数，而是预判退出时哪些资源还“活着”、哪些已不可用。与其反复调试 try/except SystemExit 的嵌套深度，不如把清理逻辑压进 atexit，然后专注验证它在各种退出路径下是否真的跑通。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
