在C语言程序正常终止时，我们常常需要执行一些收尾工作，比如关闭日志文件、释放动态分配的资源或者打印统计信息。标准库提供了两种用于注册“进程退出前自动执行函数”的机制，分别是atexit和on_exit。虽然它们看起来都是注册退出回调，但在函数签名、参数传递能力、调用顺序以及可移植性方面存在实质差异。弄清楚这些差异，能帮你在设计程序生命周期管理时少踩坑。
一、atexit的基本用法与原理
atexit是C89/C99标准明确规定的函数，几乎在所有支持C语言的环境中都能使用。它的作用是把一个函数指针注册到进程退出处理栈中，当程序通过exit或main返回而正常终止时，这些函数会被自动调用。值得注意的是，atexit注册的回调函数必须形如void func(void)，也就是既不能接收参数，也没有返回值。
调用顺序上，atexit遵循“后注册先执行”的栈式规则。也就是说，如果先注册A再注册B，那么进程退出时会先调用B，再调用A。这一设计方便了资源依赖管理，例如后申请的锁或句柄可以先被释放。下面的代码演示了atexit的典型用法：
#include <stdio.h>
#include <stdlib.h>
void clean_up_a(void) {
printf("清理模块An");
}
void clean_up_b(void) {
printf("清理模块Bn");
}
int main(void) {
atexit(clean_up_a);
atexit(clean_up_b);
printf("主逻辑执行中n");
return 0;
}
上面这段程序运行后，输出顺序会是“主逻辑执行中”“清理模块B”“清理模块A”。由于atexit属于标准C，在Windows的MSVC、Linux的gcc以及嵌入式编译器中均可编译通过，是跨平台退出清理的首选方案。
不过atexit的局限也很明显：回调函数拿不到进程最终的退出码，也无法在注册时绑定自定义参数。如果你的清理函数需要根据不同退出原因做不同处理，atexit就不够用了，这时就要考虑on_exit或者自行维护全局状态。
二、on_exit的扩展能力与局限
on_exit并不是C标准的一部分，它最早出现在GNU C库（glibc）中，后来也被一些Unix-like系统作为扩展提供。与atexit不同，on_exit允许注册的函数原型为void func(int status, void *arg)，其中status是传给exit的参数（即退出码），arg是注册时由程序员传入的任意指针。这样清理函数就能知道进程是怎么退出的，并且可以携带上下文。
从调用顺序看，on_exit与atexit一样采用逆序调用，而且atexit和on_exit注册的函数共享同一个退出处理栈，彼此按照注册先后统一逆序执行。下面示例展示了on_exit如何接收退出码和参数：
#include <stdio.h>
#include <stdlib.h>
void my_exit(int status, void *arg) {
printf("退出码=%d, 附加信息=%sn", status, (char *)arg);
}
int main(void) {
on_exit(my_exit, "来自主函数");
printf("程序即将退出n");
exit(3);
}
编译运行后，程序会打印“程序即将退出”以及“退出码=3, 附加信息=来自主函数”。可以看到，on_exit确实把exit的参数和注册时的指针都交给了回调函数，这在进行细粒度资源回收或诊断日志时非常实用。
但必须强调的是，on_exit的可移植性很差。在BSD系列、macOS的某些版本以及非glibc的嵌入式环境中，可能根本没有这个函数，编译阶段就会报隐式声明或链接错误。因此如果目标平台不确定，应尽量避免使用on_exit，或者借助条件编译来降级到atexit方案。
三、二者的核心区别对比
为了更直观地理解atexit和on_exit的差异，我们可以从多个维度进行对照。下表列出了它们在标准归属、函数签名、参数能力和移植性上的关键不同：
| 对比维度 | atexit | on_exit |
|---|---|---|
| 标准来源 | C89/C99国际标准 | GNU扩展，非C标准 |
| 回调函数签名 | void (*)(void) | void (*)(int, void *) |
| 能否获取退出码 | 不能 | 能通过第一个参数获取 |
| 能否传自定义参数 | 不能 | 能通过第二个参数获取 |
| 调用顺序 | 逆序（后注册先调用） | 逆序（与atexit共用栈） |
| 跨平台支持 | 几乎所有C环境 | 主要限glibc及部分Unix |
从工程角度看，如果你的程序只跑在Linux服务器且明确依赖glibc，on_exit带来的退出码和参数确实能简化清理逻辑；但如果要发布库文件或跨平台命令行工具，atexit才是稳妥选择。有些团队会用宏封装一层退出注册接口，在支持on_exit时启用扩展能力，不支持时退化为atexit，从而兼顾灵活性与兼容度。
另外要注意，无论是atexit还是on_exit，注册的回调函数内部都不应该再调用exit，否则会造成无限递归或栈溢出。同时，若进程被信号强制杀死（如SIGKILL），这些退出处理函数都不会被执行，它们仅对“正常终止”生效。
四、实践中的选择建议
在真实项目中，我更倾向于把atexit作为默认机制。比如后台服务需要在退出时刷盘并关闭监听套接字，用atexit注册一个无参清理函数就够了，因为退出原因通常已经在日志中记录，不需要传递给回调。只有当清理动作强烈依赖退出状态码，或者需要把某个配置结构体指针带进清理函数时，才会考虑on_exit，并配合编译探测。
下面给出一个兼容写法示例，利用预定义宏判断是否可使用on_exit：
#include <stdio.h>
#include <stdlib.h>
#ifdef __GLIBC__
#include <stdlib.h>
void ext_exit(int s, void *a) {
printf("glibc退出:%d %sn", s, (char *)a);
}
#else
void std_exit(void) {
printf("标准退出清理n");
}
#endif
int main(void) {
#ifdef __GLIBC__
on_exit(ext_exit, "ctx");
#else
atexit(std_exit);
#endif
exit(0);
}
这种写法在glibc环境下利用on_exit拿到退出信息，在其他环境退化为atexit，既满足了功能需求，也避免了移植失败。总之，理解atexit和on_exit的区别，核心在于认清“标准vs扩展”以及“无参vs带参”的权衡，根据目标平台与功能复杂度做合理选型即可。
atexiton_exitexit_handler修改时间：2026-08-02 01:18:39