Python 中有两个看起来都能“退出程序”的函数：
sys.exit(0)
os._exit(0)
它们最终都可能让进程消失，但中间经过的路径完全不同：
sys.exit() 先在 Python 层抛出 SystemExit，让程序有机会展开调用栈并正常清理；os._exit() 直接进入操作系统提供的立即退出路径，跳过 Python 解释器的正常收尾。
这种区别会直接影响 finally、上下文管理器、atexit 回调、日志、文件缓冲区、线程以及 fork() 后的子进程。本文从 CPython 和操作系统两个层次解释二者的机制，并给出实际工程中的选择方法。
一、先看结论
| sys.exit() | os._exit() |
|---|
| | |
| | |
finally | | |
with | | |
atexit | | |
| | |
| | |
| | |
| | fork() |
日常业务代码优先使用 sys.exit()。只有明确知道为什么必须绕过清理流程时，才应使用 os._exit()。
二、sys.exit 的本质是抛出异常
从 Python 语义看：
sys.exit(code)
基本等价于：
raise SystemExit(code)
在 CPython 源码中，sys.exit() 的实现并不直接调用操作系统退出函数。它主要做的事情是设置一个 SystemExit 异常，然后像其他 Python 异常一样返回到解释器的异常处理流程。
可以把调用路径简化为：
sys.exit(code)
|
v
抛出 SystemExit(code)
|
v
沿调用栈向外传播
|
+--> 被捕获：程序可以继续运行
|
+--> 未被捕获并到达主线程顶层
|
v
CPython 计算退出状态
|
v
执行解释器正常清理
|
v
操作系统结束进程
1. 为什么 finally 仍然会执行
因为 SystemExit 仍是异常，所以异常传播时会进行正常的栈展开。栈展开经过的 finally 和上下文管理器退出逻辑都会执行：
import sys
try:
print("开始处理")
sys.exit(2)
finally:
print("释放资源")
输出中会包含：
开始处理
释放资源
同理，下面的文件会正常离开 with 块：
import sys
with open("result.txt", "w", encoding="utf-8") as file:
file.write("done\n")
sys.exit(0)
with 对应的 __exit__() 会被调用，文件对象有机会刷新并关闭。
不过要注意，sys.exit() 只能保证执行异常传播路径上遇到的清理代码。它不能保证所有对象的 __del__() 都以某个固定顺序执行，也不能替代显式的 with 或 try...finally。
下面用两个例子说明这种区别。
例一：不要依赖 __del__ 的执行顺序
假设一个对象代表日志文件，另一个对象在销毁时还想向这个日志文件写入消息：
import sys
class LogFile:
def write(self, message):
print(f"LOG: {message}")
def __del__(self):
print("销毁 LogFile")
class Worker:
def __init__(self, logger):
self.logger = logger
def __del__(self):
self.logger.write("销毁 Worker")
logger = LogFile()
worker = Worker(logger)
sys.exit(0)
不能根据对象的创建顺序推断退出时一定先执行 Worker.__del__()，再执行 LogFile.__del__()。对象之间可能存在其他引用或循环引用，模块全局变量也会在解释器关闭期间被逐步清理；具体终结时机和顺序可能受到 Python 实现及版本影响。
如果 Worker.__del__() 执行时依赖的对象已经不可用，它还可能抛出异常。__del__() 中未处理的异常只会被打印到标准错误，无法像普通异常一样可靠地阻止或修正退出流程。
即使某次运行恰好输出：
LOG: 销毁 Worker
销毁 LogFile
也不应该把这个观察结果当作稳定接口。只要业务上要求“必须先停止 Worker，再关闭日志”，就应显式表达这个顺序。
例二：用 finally 明确清理顺序
import sys
class Worker:
def stop(self):
print("1. 停止 Worker")
class LogFile:
def close(self):
print("2. 刷新并关闭日志")
worker = Worker()
logger = LogFile()
try:
print("执行任务")
sys.exit(1)
finally:
worker.stop()
logger.close()
因为 SystemExit 遵循正常的异常传播规则，finally 中的代码会在退出前按书写顺序执行：
执行任务
1. 停止 Worker
2. 刷新并关闭日志
对于单个资源，上下文管理器通常更简洁：
import sys
with open("result.txt", "w", encoding="utf-8") as file:
file.write("任务结果\n")
sys.exit(0)
退出 with 代码块时，文件的 __exit__() 会在异常继续向外传播前关闭文件。这里依赖的是明确的上下文管理协议，而不是等待垃圾回收器以后调用文件对象的终结逻辑。
因此，几种机制的职责可以概括为：
__del__()：对象被终结时的兜底逻辑，不适合承载有严格时序要求的业务清理；withtry...finallysys.exit()
2. SystemExit 为什么通常不会被误捕获
异常继承关系中，SystemExit 直接继承自 BaseException，而不是普通的 Exception：
BaseException
├── SystemExit
├── KeyboardInterrupt
├── GeneratorExit
└── Exception
├── ValueError
├── RuntimeError
└── ...
因此下面的代码不会拦住 sys.exit()：
try:
sys.exit(1)
except Exception:
print("不会执行")
但捕获 SystemExit 或 BaseException 可以阻止退出：
try:
sys.exit(1)
except SystemExit as exc:
print(f"拦截退出，退出参数是 {exc.code!r}")
print("程序继续运行")
这也是为什么业务代码通常不应随意写 except BaseException:。它不仅会捕获业务异常，还可能吞掉退出请求和 Ctrl+C 对应的 KeyboardInterrupt。
3. sys.exit 在工作线程中不会结束整个进程
SystemExit 只会沿当前线程的 Python 调用栈传播。如果在工作线程中调用 sys.exit()，且异常没有被该线程捕获，通常只是该线程结束，其他线程和整个进程仍然存在：
import sys
import threading
import time
def worker():
print("工作线程准备退出")
sys.exit(5)
thread = threading.Thread(target=worker)
thread.start()
thread.join()
print("主线程仍在运行")
time.sleep(1)
如果工作线程发现了必须结束整个程序的错误，更常见的做法是：
- 通过
threading.Event、队列或共享状态通知主线程；
下面是一个简化但完整的例子。工作线程不直接结束进程，而是把执行结果放进队列；如果发生致命错误，它还会设置 stop_event，通知其他线程协作退出。主线程负责汇总结果、等待线程清理，最后返回统一退出码：
import queue
import sys
import threading
import time
stop_event = threading.Event()
result_queue = queue.Queue()
def worker(name, fail=False):
status = "success"
error = None
try:
for step in range(5):
if stop_event.is_set():
status = "cancelled"
print(f"{name}: 收到停止通知")
break
print(f"{name}: 执行第 {step + 1} 步")
time.sleep(0.1)
if fail and step == 1:
raise RuntimeError("数据库连接已损坏")
except Exception as exc:
status = "error"
error = exc
# 工作线程只报告错误并发出停机信号，不调用 sys.exit()。
stop_event.set()
finally:
print(f"{name}: 清理线程资源")
# 无论成功、失败还是取消，每个线程都恰好上报一次结果。
result_queue.put((status, name, error))
def main():
threads = [
threading.Thread(target=worker, args=("worker-1", True)),
threading.Thread(target=worker, args=("worker-2",)),
]
for thread in threads:
thread.start()
errors = []
# 收齐所有线程的结果，避免因上报顺序不同而误判成功。
for _ in threads:
status, name, error = result_queue.get()
if status == "error":
errors.append((name, error))
print(f"主线程收到 {name} 的致命错误：{error}", file=sys.stderr)
# 实际服务可在这里停止监听或停止向任务队列投放新任务。
stop_event.set()
# 等待所有工作线程完成 finally 中的清理。
for thread in threads:
thread.join()
return 1 if errors else 0
if __name__ == "__main__":
sys.exit(main())
这个例子中的控制关系是：
工作线程发生致命错误
|
+--> result_queue：把异常交给主线程
|
+--> stop_event：通知其他线程停止工作
|
v
主线程停止接收新任务并等待所有线程
|
v
工作线程执行 finally 清理
|
v
主线程返回退出码 1
|
v
sys.exit(1)
这里的关键不是一定要同时使用队列和 Event，而是把职责分开：工作线程负责报告错误，Event 负责广播停机请求，主线程负责协调生命周期和决定进程退出码。实际服务中，主线程还可以在 join() 前关闭监听 socket、停止从消息队列取新任务，或者为线程退出设置超时。
三、sys.exit 的退出码如何计算
常见写法是：
sys.exit(0) # 成功
sys.exit(1) # 一般性失败
sys.exit(2) # 某类具体错误
SystemExit.code 不一定必须是整数，CPython 会按下面的规则处理：
所以：
sys.exit("配置文件不存在")
会把提示写到标准错误，并以失败状态退出。这适合很小的脚本，但大型 CLI 通常更适合先用日志或参数解析器输出结构化错误，再明确返回整数退出码。
在 Linux 和其他 Unix 系统中，父进程或 Shell 通常只能观察到退出状态的低 8 位。因此工程上最好使用 0 到 255 之间的值，并遵循“0 表示成功，非 0 表示失败”的约定：
python app.py
echo $?
另一个少见但重要的细节是：如果 CPython 捕获到 SystemExit 后，在解释器最终清理或刷新标准流时又发生错误，最终退出码可能被改成 120。
四、sys.exit 后 CPython 会做哪些清理
未被捕获的 SystemExit 到达主程序顶层后，CPython 会进入正常的解释器终止流程。不同 Python 版本的内部顺序和实现细节可能变化，但对应用层来说，关键行为包括：
- 执行通过
atexit.register() 注册的回调； - 执行正常栈展开中遇到的
finally 和上下文管理器退出逻辑；
例如：
import atexit
import sys
@atexit.register
def goodbye():
print("atexit: 保存退出信息")
try:
print("准备退出")
sys.exit(0)
finally:
print("finally: 释放当前作用域资源")
finally 属于异常栈展开，atexit 属于解释器正常终止，它们是两套不同的机制，正常情况下都会有机会执行。
但“会进行正常清理”不等于“任何情况下都能安全保存数据”。例如：
- 进程收到
SIGKILL 时没有执行 Python 清理的机会； - 进程崩溃或机器断电时，
atexit 无法提供保证； __del__()- 非守护线程没有结束时，程序可能暂时无法完成正常退出；
重要数据应在业务事务完成时及时持久化，而不是全部押在退出阶段。
五、os._exit 的底层机制
os._exit(status) 没有走 Python 异常机制。在 CPython 中，它会很快进入 C 层的立即退出函数。
在 POSIX 系统上，调用路径可以概括为：
Python os._exit(status)
|
v
CPython 的 os._exit 实现
|
v
C 运行库 _exit(status)
|
v
操作系统终止进程
在现代 Linux 的 glibc 中，_exit() 包装函数通常会使用 exit_group，使整个多线程进程终止。这里要区分 glibc 的 _exit() 包装函数和 Linux 内核中同名的原始系统调用：后者在底层线程语义上有所不同。对普通 CPython 程序来说，实际可见效果是整个进程立即结束，而不是只退出调用它的 Python 线程。
Windows 的底层实现细节不同，但 Python 层语义相同：不执行 Python 的正常清理处理，直接终止进程。
1. “不清理”具体指什么
下面的代码中，finally 和 atexit 都不会执行：
import atexit
import os
@atexit.register
def goodbye():
print("不会执行 atexit")
try:
print("即将强制退出", flush=True)
os._exit(7)
finally:
print("不会执行 finally")
这里给第一条 print() 加了 flush=True，否则这行文字本身也可能因为仍在用户态缓冲区中而丢失。
os._exit() 会跳过的主要是用户态清理，包括：
finallyatexit- Python I/O 对象和 C 标准 I/O 缓冲区的正常刷新；
2. 操作系统仍然会回收内核资源
“不清理”不代表进程占用的一切都会永久泄漏。进程终止后，操作系统仍会回收属于该进程的内核资源，例如：
关键区别在于：内核只负责终止进程和回收内核资源，不会替应用完成用户态协议。
例如，文件描述符最终会被关闭，但 Python 缓冲区中尚未交给内核的数据不会自动写入；数据库连接会断开，但应用计划发送的 COMMIT 不会凭空执行；锁文件对应的文件描述符可能关闭，但程序自定义创建的锁文件路径不会自动删除。
六、用实验观察缓冲区差异
先看 sys.exit()：
# sys_exit_demo.py
import sys
file = open("sys-result.txt", "w", encoding="utf-8")
file.write("这段内容还在 Python 缓冲区中")
sys.exit(0)
正常解释器退出时，文件对象通常会被刷新和关闭，内容会写入文件。
再看 os._exit()：
# os_exit_demo.py
import os
file = open("os-result.txt", "w", encoding="utf-8")
file.write("这段内容还在 Python 缓冲区中")
os._exit(0)
第二段代码中的文件可能被创建，但内容为空，因为数据还在 Python 用户态缓冲区里。内核虽然关闭了底层文件描述符，却根本没有收到那段待写入的数据。
如果确实要在 os._exit() 前保留数据，必须在退出前显式完成所需动作：
file.flush()
os.fsync(file.fileno())
os._exit(0)
其中：
flush()fsync()- 二者解决的问题不同，是否需要
fsync() 取决于数据持久性要求。
不过，如果已经需要执行复杂的保存和清理逻辑，通常说明这个场景更适合正常退出，而不是 os._exit()。
七、为什么 fork 后的子进程常用 os._exit
os._exit() 最典型的场景是 Unix 的 fork()。
fork() 会复制当前进程，子进程会继承父进程在 fork 时刻的用户态内存状态，包括：
假设父进程在 fork() 前有一段尚未刷新的输出：
import os
import sys
sys.stdout.write("任务开始 ")
pid = os.fork()
if pid == 0:
sys.exit(0)
os.waitpid(pid, 0)
sys.exit(0)
父子进程各自都有一份 stdout 用户态缓冲区。如果两边都正常退出并刷新缓冲区，任务开始 就可能被输出两次。这在输出被重定向到文件或管道时尤其容易观察到。
如果子进程的使命只是执行少量底层操作，随后退出或调用 exec() 替换自己，就不应该重复运行继承自父进程的 Python 清理逻辑。典型模式是：
import os
pid = os.fork()
if pid == 0:
try:
os.execvp("some-command", ["some-command", "--help"])
except OSError:
os._exit(127)
_, wait_status = os.waitpid(pid, 0)
exit_code = os.waitstatus_to_exitcode(wait_status)
print(f"子进程退出码：{exit_code}")
成功调用 execvp() 后，当前子进程映像会被新程序替换，不会返回。只有 execvp() 失败时才会继续执行，此时使用 os._exit(127) 可以避免：
127 常被 Shell 用来表示命令未找到或无法执行，具体项目也可以定义自己的退出码。
需要特别注意：多线程程序在 fork() 后，子进程只保留调用 fork() 的线程，其他线程消失，但它们持有的锁状态可能被复制下来。这使子进程在 exec() 前调用复杂的 Python 或 C 库代码存在死锁风险。实际工程中应优先使用 subprocess.run()、subprocess.Popen() 或合适的 multiprocessing 启动方式，把这些底层细节交给标准库处理。
八、实际应用中怎么选
场景一：命令行程序正常结束
使用 sys.exit()，或者让 main() 返回退出码后统一退出：
import sys
def main() -> int:
if not load_config():
print("配置加载失败", file=sys.stderr)
return 2
run_task()
return 0
if __name__ == "__main__":
sys.exit(main())
这种写法的优点是业务函数仍然可以测试，退出动作集中在程序入口处。
场景二：库函数遇到错误
库代码通常不要调用 sys.exit()，更不要调用 os._exit()。应抛出有意义的异常，让上层应用决定重试、降级还是退出：
class ConfigError(Exception):
pass
def load_config(path):
if not path.exists():
raise ConfigError(f"配置文件不存在: {path}")
否则，只是导入并调用这个库的程序可能被库强行终止，调用者也很难恢复或测试。
场景三：服务进程优雅停机
收到终止信号后，不要把 os._exit() 当作默认方案。服务通常需要：
如果进程已经死锁、解释器状态损坏，或者清理代码本身会永久阻塞，监管进程才可能在超时后使用强制终止手段。os._exit() 可以作为进程内部的最后手段，但它意味着接受日志和数据丢失风险。
场景四：fork 后的子进程执行失败
这是 os._exit() 最合理的使用场景。子进程无法 exec() 新程序时，应以明确的非零状态立即退出，避免运行父进程的清理流程。
不过应用代码通常无需手写 fork + exec。subprocess 和 multiprocessing 内部已经针对平台、线程、文件描述符和退出流程处理了许多边界情况。
场景五：测试退出行为
因为 sys.exit() 是 SystemExit，单元测试可以直接断言退出码，而不必真的杀死测试进程：
import pytest
def test_main_exits_with_error():
with pytest.raises(SystemExit) as exc_info:
main(["--invalid"])
assert exc_info.value.code == 2
不要在单元测试进程中直接调用包含 os._exit() 的路径，否则测试运行器也会被终止。应把它放到独立子进程中测试，再由父进程检查返回码：
import subprocess
import sys
result = subprocess.run(
[sys.executable, "force_exit_demo.py"],
check=False,
)
assert result.returncode == 7
九、几个常见误区
误区一：sys.exit 一定会结束整个程序
不一定。它可能被捕获；在工作线程中调用时，通常只结束当前线程。只有未被捕获的 SystemExit 到达主线程顶层，才通常导致整个解释器退出。
误区二：os._exit 会导致文件描述符永久泄漏
不会。操作系统会关闭进程的文件描述符并回收内核资源。真正丢失的是尚未从用户态缓冲区写给内核的数据，以及应用层本应执行的协议和清理动作。
误区三：调用 close 就等于数据已经安全落盘
不完全是。关闭或 flush() 通常只是把 Python 缓冲区中的数据交给操作系统；如果要求断电后也尽量保留，还要结合 fsync()、文件系统和存储设备语义设计持久化方案。
误区四：os._exit 比 sys.exit 更可靠
它只是更直接，不是普遍意义上的更可靠。它能绕过卡住或不安全的清理流程，但代价是跳过本来应该执行的清理，并可能丢失日志和数据。
误区五：结束函数就应该调用 sys.exit
普通函数结束应使用 return。sys.exit() 表达的是“请求终止当前 Python 执行流程”，适合放在应用入口层，而不是作为普通控制流工具散落在业务函数里。
十、选择原则
可以用下面这套判断方法：
只是结束当前函数？
|
+--> 使用 return
库函数报告错误？
|
+--> 抛出业务异常
应用需要正常结束并执行清理？
|
+--> 使用 sys.exit() 或从 main() 返回
fork 后的子进程必须立即退出，且不能执行继承来的清理？
|
+--> 使用 os._exit()
进程已处于无法安全清理的致命状态？
|
+--> 评估数据丢失后，将 os._exit() 作为最后手段
最后可以把二者记成两句话：
sys.exit() 是向 Python 解释器提出一个可以被处理的退出请求。
os._exit() 是绕过 Python 清理，直接要求操作系统结束进程。
绝大多数应用代码需要的是前者。后者不是“更强的 sys.exit”，而是面向 fork 和异常运行时状态的一条特殊逃生路径。
10个月宝宝每天需要喝多少奶粉？
