C语言回调函数实战：从函数指针到事件框架与避坑指南

带过几届刚入行的同学之后，我发现一个挺有意思的规律：判断一个人C语言到底学没学透，分水岭往往不是指针本身，而是他能不能把回调函数用得自然。指针考的是你懂不懂内存，回调函数考的则是你有没有"把代码当积木搭"的思维——这是一种从"写函数"到"设计接口"的跨越。很多人卡在这一步，不是因为语法难，而是因为脑子里没有建立起"函数也能像变量一样被传来传去"的模型，结果看到void (*cb)(int)这种声明就发怵，看到别人写的注册-触发框架就觉得玄乎。其实把回调函数拆开看，它一点都不神秘：它就是一个普通的函数指针，被当作参数交给另一个函数，在合适的时机被回头调用而已。这篇文章我会从最基础的函数指针讲起，一路讲到寄存器回调、事件框架、异步生命周期管理，再把我这些年踩过的段错误、野指针、可重入问题一次性摊开讲清楚。不管你是刚看完C语言基础、正在啃指针的新手，还是写嵌入式、写中间件的老手，都能从里面找到能直接用上的东西。下面这些内容，你可以当成一份回调函数的完整地图，也可以当成查手册，遇到坑的时候翻出来对一对。

1. 先把回调函数这件事说透：它到底解决什么问题

1.1 从一次真实的代码返工说起

我印象特别深的一个项目，是给一台采集设备做数据处理。最初的需求很简单：采集到一帧数据就存进文件。于是我在主循环里直接写了写文件的逻辑，跑得挺好。过了一个月，产品说还要把数据同步上送到另一个模块；再过两周，又说要加一个阈值报警。这时候问题就来了——主循环里那段处理代码被我改了七八遍，每加一个功能就要进去插一段if，最后那个函数长到三百多行，谁都不敢动。

后来我把结构重写了一遍：主循环只管采集，采到数据后调用一个"处理入口"，而这个"处理入口"具体干什么，由注册进来的回调决定。写文件的注册写文件的回调，报警的注册报警的回调，上送的注册上送的回调。主循环从此再没改过。这个改动看起来只是把代码挪了个位置，但它带来的核心价值是解耦：调用方和实现方不再互相认识，双方只认一个函数签名。这就是回调函数最本质的用途——把"什么时候调用"和"调用时做什么"这两件事拆开，让它们各自独立演化。

我后来复盘这次返工，发现问题根源不在于我写得差，而在于一开始需求是模糊且会变的。回调函数恰好是应对"变化点"的利器：凡是那些"大部分流程固定、只有一小段逻辑会变"的地方，都适合用回调把变化点抽出来。

1.2 回调的本质：把函数当作参数传进去

用一句话概括回调：把函数的地址作为参数传递给另一个函数，由那个函数在内部某个时机通过这个地址去调用它。这里被传进去的函数就叫"回调函数"，接收它的那个函数通常叫"调用方"或者"框架"。

打个生活化的比方。你装修房子，你不会自己天天守在工地，而是把钥匙交给工长，跟他说"水电做完给我打个电话，我过来验收"。这里"给你打电话"就是你交给工长的回调，工长就是框架，他在水电这个时机点触发你的回调。你自己完全不用管他什么时候铺砖、什么时候刷墙，你只关心你需要被通知的那一刻。

放到代码里，这个"电话"就是函数地址。C语言里函数名本身就是地址，所以传回调就是传函数名（或者传&函数名，效果一样）。框架拿到这个地址后，用一个函数指针去存它，等到需要的时候用fp(...)或者(*fp)(...)的方式触发。

理解了这个模型，很多困惑就解开了。比如为什么回调函数的签名（参数类型、返回值类型）必须由框架规定死？因为框架要在内部用它自己的参数去调用它。就像工长给你打电话只会说"水电好了"，他不会问你希望他用什么语言报喜——格式是双方约定好的，谁都不能改。

1.3 什么样的场景该用回调，什么场景不该用

回调好用，但不是万能。我这些年总结下来，判断标准其实很朴素：当调用方无法预知、也不该预知具体行为时，用回调；当调用方明明知道要做什么时，别用回调。

典型的该用回调的场景有这么几类。第一类是通用算法需要定制比较或操作，比如qsort、bsearch，它们排序、查找的逻辑是固定的，但"谁大谁小""算不算相等"得由你定。第二类是事件驱动，比如按键按下、数据到达、定时器超时，这些事件什么时候来框架不知道，来了之后干什么框架也不关心。第三类是分层解耦，上层模块注册回调给下层，下层只负责在合适时机回调，不依赖上层实现，反向依赖就断开了。第四类是异步与延迟执行，比如网络请求完成后的处理、线程池任务的完成通知，这个在执行异步的时候会重点讲到。

反过来的场景也很有代表性。如果一段逻辑只会有一个实现，而且短期内不可能变，那么直接函数调用就行，套一层回调纯属增加阅读成本。我见过有人在只需要打印日志的地方，都先注册一个回调再触发，读数的人得跳三层才看到printf，这就是典型的过度设计。回调是给"变化"和"解耦"买单的，如果没有这两个需求，它就是纯粹的负担。

提示：判断要不要用回调，先问自己一句——"这块逻辑未来有几种实现？会不会被不同调用方替换？"答案如果是"只有一种且不会变"，直接用函数调用。

2. 函数指针是绕不过去的地基

2.1 指针函数和函数指针别再搞混了

几乎所有回调函数讲不明白的地方，根子都在函数指针没学利索。而函数指针的第一个门槛，就是和指针函数分清楚。这俩名字只差一个字，含义天差地别，我把它们并排放一起看：

int *func(int a); /* 指针函数：返回值是 int* 的函数 */ int (*fp)(int a); /* 函数指针：指向"参数int、返回int"函数的指针 */

记忆方法很简单：看括号和谁离变量名近。int *func(int a)里，func先和(int a)结合，说明func是个函数，前面的int*是它的返回类型，这叫"指针函数"——一个返回指针的函数。而int (*fp)(int a)里，因为有那对括号，*先和fp结合，说明fp是个指针，指向的是一个int (int)类型的函数，这就是"函数指针"。

我当年背的口诀是"有括号是函数指针，没括号是指针函数"，虽然粗糙但够用。你可以自己动手验证：写int (*fp)(int) = NULL;能编译过，写int fp(int) = NULL;编译器会直接报错，因为它不允许你把一个函数赋值为NULL。这个小实验做过一次，基本就不会再混了。

2.2 函数指针的声明、赋值与调用

函数指针的完整用法分三步：声明、赋值、调用。声明时把函数原型里的函数名换成(*指针名)即可，参数列表和返回值保持一致：

/* 声明一个指向"两int进、一int出"函数的指针 */ int (*operation)(int, int); /* 定义两个符合签名的普通函数 */ int add(int a, int b) { return a + b; } int sub(int a, int b) { return a - b; } /* 赋值：函数名就是地址，加&也一样 */ operation = add; /* 调用：两种写法等价，推荐第一种 */ int r1 = operation(3, 4); /* 6行老手常用 */ int r2 = (*operation)(3, 4); /* 更强调"这是指针" */

调用这里有个细节值得说：operation(...)和(*operation)(...)在C语言里完全等价，因为函数调用运算符()会自动把函数指针解引用。很多老代码喜欢写后者，理由是"一看就知道是指针"，我个人更推荐前者，因为它和普通函数调用长得一样，读起来顺。但在团队里，统一风格比分出优劣更重要——如果项目里大家都写(*fp)()，你就跟着写，别自己搞一套。

赋值的时机可以在声明时直接给，也可以运行时换。这点正是回调的威力所在：同一个函数指针变量，在运行时可以指向不同的实现，这就为"动态替换行为"提供了可能。

2.3 typedef 让回调签名一眼看懂

原始的函数指针声明一旦参数变多就很难看，比如"参数是const char*和void*、返回int"的函数指针：

int (*handler)(const char *name, void *userdata);

这种还勉强能读，要是再来个指向函数的指针的数组，基本就成天书了。这时候typedef就是救命稻草。它把类型和变量名分离开，给函数指针类型起个名字：

typedef int (*handler_t)(const char *name, void *userdata); /* 现在声明变得清爽 */ handler_t on_message; handler_t handlers[8]; /* 甚至可以做成数组 */

我强烈建议所有对外暴露的回调，都用typedef定义成一个带_t后缀的类型名。好处有三个：一是调用方注册时只看类型名就知道签名，不用去数括号；二是框架内部改签名时，只改一处typedef，全局报错帮你找齐所有问题；三是代码可读性直线上升，on_message一眼就知道它是消息处理回调。这个习惯我从写第一个中间件起就保持了，后来无论写嵌入式还是写服务端，都没吃过亏。

2.4 数组、结构体中的函数指针

函数指针一旦放进结构体，代码的组织方式就完全不一样了。这也是C语言实现"面向对象"和"多态"的核心套路。看这个例子：

typedef struct { const char *name; void (*init)(void); void (*process)(int data); void (*deinit)(void); } driver_t; void uart_init(void) { /* ... */ } void uart_process(int data) { /* ... */ } driver_t uart_driver = { .name = "uart", .init = uart_init, .process = uart_process, .deinit = NULL, };

这段代码的意义在于：它把一个"驱动"的接口和行为打包在了一起。上层代码拿到一个driver_t*，直接调drv->process(0x55)，根本不需要知道底层是UART还是别的什么。换一个驱动只要换结构体实例，调用代码一行不用动——这就是C语言里的多态。

我在嵌入式项目里几乎每个外设驱动都是这个结构。它的好处在移植时体现得最清楚：换芯片时，只要新写一个结构体实例把函数指针填上，上层业务完全不受影响。唯一要小心的是空指针判断——有些接口可能是可选的，比如deinit，调用前务必if (drv->deinit) drv->deinit();，否则就是稳定的崩溃。

3. 回调函数的几种典型写法与实现细节

3.1 最基础的一层回调：注册-调用模型

回调最常见的落地形态就是"注册-调用"两段式。框架提供一个注册接口，让调用方把回调塞进来；框架在合适的时候把它取出来执行。这是一个最小可用的例子：

typedef void (*data_cb_t)(int value); static data_cb_t g_cb = NULL; /* 注册接口 */ void register_callback(data_cb_t cb) { g_cb = cb; } /* 触发接口，模拟数据到达 */ void on_data_arrived(int value) { if (g_cb != NULL) { g_cb(value); } } /* 使用方 */ void my_handler(int value) { printf("收到数据: %d\n", value); } int main(void) { register_callback(my_handler); on_data_arrived(42); return 0; }

这段代码虽小，但把回调的核心骨架全包括进去了。里面有两个关键设计要点必须说清楚。第一，注册时一定要保存，触发时一定要判空。如果g_cb没判空就直接调，那在你注册之前任何一次数据到达都会直接把程序送走。第二，回调最好不要在触发点直接做重活。我最早写的时候，在my_handler里直接写文件、发网络包，结果主循环被卡住，数据处理不过来开始丢帧。后来我把回调改成"只是投递到队列"，真正的处理放到另一个任务里，问题立刻缓解。

这个模型还能扩展。比如支持多个回调，就把g_cb换成数组或者链表；支持注销，就加一个按函数地址查找并置空的接口。下面几个小节会逐步把这块补全。

3.2 带上文指针 void *ctx：解耦的关键一招

上面那个例子有个硬伤：回调函数签名里没有"调用方的身份信息"，所以回调里想用到注册者的私有数据就很别扭。解决方案是加一个void *类型的上下文指针，行业里通常叫ctx、userdata或者arg：

typedef void (*timer_cb_t)(void *ctx); typedef struct { timer_cb_t cb; void *ctx; int expire_ms; } timer_t; void timer_start(timer_t *t, timer_cb_t cb, void *ctx, int ms) { t->cb = cb; t->ctx = ctx; t->expire_ms = ms; } void timer_tick(timer_t *t) { if (t->expire_ms > 0) { t->expire_ms--; } if (t->expire_ms == 0 && t->cb != NULL) { t->cb(t->ctx); /* 把上下文原样交还给回调 */ } }

void *ctx之所以是经典设计，是因为它把"回调怎么拿到自己的数据"这个问题甩给了使用者，框架本身不需要知道ctx里装的是什么。回调里只要把void*强转回真实类型就能用：

typedef struct { int fd; char name[32]; } conn_t; void on_timeout(void *ctx) { conn_t *conn = (conn_t *)ctx; printf("连接 %s 超时, fd=%d\n", conn->name, conn->fd); close(conn->fd); }

这里有个必须强调的注意事项：ctx指向的内存生命周期必须覆盖回调的整个可能触发期。我曾经在一个网络模块里，把一个栈上的局部变量地址当ctx注册进去，函数返回后那块栈内存就被复用了，回调触发时读到的是一堆随机值，排查了整整一个下午。经验就是——要么ctx指向堆上分配且由明确的一方释放，要么指向生命周期最长的全局/静态对象，绝对不要指向局部栈变量。

3.3 结构体+函数指针：C语言里的"接口"与多态

把回调组织成"结构体里装一组函数指针"，就得到了C语言中最接近"接口"的东西。前面驱动的例子已经展示过基本形态，这里补充一种更工程化的写法——用回调结构体实现上下层分离：

/* 底层提供的抽象接口，由上层实现 */ typedef struct { int (*read)(void *ctx, char *buf, int len); int (*write)(void *ctx, const char *buf, int len); void (*error)(void *ctx, int code); } io_ops_t; /* 底层核心逻辑，只依赖接口，不依赖具体实现 */ int protocol_send(io_ops_t *ops, void *ctx, const char *data, int len) { int n = ops->write(ctx, data, len); if (n < 0 && ops->error) { ops->error(ctx, -1); } return n; }

这种模式的精髓在于：protocol_send所在的模块编译时完全不知道具体的读写是怎么实现的，它只认io_ops_t这个"合同"。上层可以拿它对接串口、网口、文件，甚至是内存缓冲区（测试时特别有用）。我做单元测试就经常这么干——写一个假的内存版io_ops_t，把整个协议层跑一遍，不需要任何真实硬件。

用这个模式有两个经验点。第一，接口结构体里的函数指针尽量保持参数一致，第一个参数固定是void *ctx，让实现方自己去转类型，这样接口才好复用。第二，可选接口要么置NULL要么提供空实现。我倾向于把非必需的接口在结构体初始化时显式写NULL，调用方判空，这样"哪些能力实现了、哪些没实现"一眼看得到。

3.4 返回值与错误码的设计

回调的返回值设计是个容易忽略但影响很大的点。它有两种主流风格：一种是回调返回一个值，框架根据这个值决定下一步；另一种是回调返回void，错误通过别的方式传递。

qsort的比较函数就是前者的典型——返回负数、零、正数分别代表小于、等于、大于，框架靠这个决定怎么排。这种设计非常高效，因为它让回调参与了框架的控制流。但代价是语义必须约定得非常清楚，你返回-1到底是"小于"还是"出错"，必须写进文档。

另一种情况是回调只是通知，不参与控制，那就返回void。但这里有同学会问：那回调内部出错了怎么办？工程上常见做法是传一个"错误码指针"或者把错误塞进上下文结构体：

typedef int (*parse_cb_t)(const char *line, int lineno, void *ctx, int *err); void parse_file(const char *path, parse_cb_t cb, void *ctx) { int err = 0; char line[256]; int lineno = 0; FILE *fp = fopen(path, "r"); if (!fp) return; while (fgets(line, sizeof(line), fp) != NULL) { lineno++; if (cb(line, lineno, ctx, &err) < 0) { fprintf(stderr, "第%d行解析失败, err=%d\n", lineno, err); break; } } fclose(fp); }

提示：不管选哪种风格，回调的错误语义一定要在头文件里写注释说清楚。我审查代码时最头疼的就是遇到"返回0到底代表成功还是失败完全靠猜"的接口。

3.5 异步与延迟回调需要注意的生命周期

当回调不是在当前调用栈里立即执行，而是被丢进队列、由别的线程或者稍后的定时器执行时，问题就从"语法"升级到"时序"了。核心矛盾是：注册回调的那一刻用的资源，到回调真正执行时可能已经失效。

最典型的场景是线程池。你提交一个任务，附带上回调；主线程继续往下走，可能已经把这个回调依赖的结构体释放了，而工作线程过一会儿才触发它，于是回调里访问悬空指针，程序崩溃。这类问题最难查，因为它不是必现，往往压测才出来。

处理这类问题，我一般用这几招。第一，明确所有权。回调依赖的资源由谁负责释放、什么时机释放，必须白纸黑字定下来。如果回调是延迟执行的，明确规定"调用方必须保证回调执行完之前资源不被释放"。第二，提供注销接口并保证同步。注销时要确保"注销返回之后，这个回调绝不会再被触发"，一般通过加锁加标志位实现。第三，用引用计数或者智能包装。给需要跨线程传的对象加一个引用计数，注册回调时加一，回调执行完减一，减到零才真正释放。

typedef struct { int refcnt; /* ... 其他数据 ... */ } shared_t; void shared_hold(shared_t *s) { s->refcnt++; } void shared_release(shared_t *s) { if (--s->refcnt == 0) { free(s); } }

这套东西看起来繁琐，但只要你写过一次"回调里访问已释放内存"的事故，就会心甘情愿地在设计阶段把它加上。我个人的规矩是：只要回调可能跨越函数返回、跨线程、跨事件循环，就必须先想清楚生命周期，再写一行代码。

4. 实战案例：手写一个轻量事件回调框架

4.1 需求与整体设计

光看零散例子不够过瘾，我们动手搭一个能在真实项目里用的小框架。需求定得很克制：支持按事件类型注册多个回调、支持注销、支持在事件到来时依次触发所有回调、要能在动态内存受限的嵌入式环境下用。为了简单，不引入动态内存分配，用固定大小的数组池。

整体设计思路是：定义一个事件类型枚举，一个回调注册项结构体，一个全局注册表（数组），然后提供 register、unregister、emit 三个接口。每个注册项记录事件类型、回调函数、上下文指针三个信息。emit时遍历注册表，把所有匹配事件类型的项依次调一遍。

选数组而不是链表，是因为场景里事件类型和注册数量都可预期，数组遍历更快也更好控制内存；选固定池而不是malloc，是因为嵌入式里最怕动态分配带来的碎片和不确定性。这两点都是基于"嵌入式场景最常见实践"的合理取舍。

4.2 数据结构定义

#define MAX_LISTENERS 32 typedef enum { EVT_DATA_READY = 0, EVT_TIMEOUT, EVT_ERROR, EVT_MAX } event_type_t; typedef void (*event_cb_t)(event_type_t type, void *ctx); typedef struct { event_type_t type; event_cb_t cb; void *ctx; int used; } listener_t; static listener_t g_listeners[MAX_LISTENERS];

这里used字段就充当一个"槽位是否被占用"的标记，替代了动态链表里"节点是否存在"的语义。EVT_MAX放在枚举最后，方便做边界检查。结构体里存type是为了emit时能快速筛选，虽然可以按类型分数组，但那样每种事件都要单独维护一个池，代码更臃肿，权衡下来单池加筛选更合适。

4.3 注册、注销与触发实现

int event_register(event_type_t type, event_cb_t cb, void *ctx) { if (type >= EVT_MAX || cb == NULL) return -1; for (int i = 0; i < MAX_LISTENERS; i++) { if (!g_listeners[i].used) { g_listeners[i].type = type; g_listeners[i].cb = cb; g_listeners[i].ctx = ctx; g_listeners[i].used = 1; return i; /* 返回槽位号，给注销用 */ } } return -1; /* 池满 */ } int event_unregister(int id) { if (id < 0 || id >= MAX_LISTENERS) return -1; if (!g_listeners[id].used) return -1; g_listeners[id].used = 0; g_listeners[id].cb = NULL; g_listeners[id].ctx = NULL; return 0; } void event_emit(event_type_t type, void *event_data) { for (int i = 0; i < MAX_LISTENERS; i++) { if (g_listeners[i].used && g_listeners[i].type == type) { g_listeners[i].cb(type, g_listeners[i].ctx); } } }

注册返回槽位号而不是指针，是刻意的设计。返回指针虽然看起来方便，但一旦数组被整体移动（虽然这里是静态的，但在别的实现里可能是可增容的），指针就悬空了。返回一个整数ID，注销时再查表，是最稳的做法。

event_emit这个函数有两个隐藏的坑必须提前说。第一是在回调里注销自己。假设某个回调在触发时调用event_unregister把自己的used置零，那当前这轮for循环需要能正确处理这种情况——因为我们是先判断used再调用，当前这次调用已经进栈了，影响不大；但如果回调注销的是后面还没遍历到的槽位，那么后面的槽位会被跳过，这是符合预期的。第二是回调里又emit同一个事件，会造成递归，如果形成环就是无限递归栈溢出。所以emit里最好加一个深度保护，或者在文档里明确禁止重入。

4.4 测试与验证

写完框架当然要跑一遍验证逻辑。我习惯写一个最简单的测试主函数，把注册、触发、注销三条路径都走一遍：

static void handler_a(event_type_t t, void *ctx) { printf("[A] 事件%d, ctx=%s\n", t, (char *)ctx); } static void handler_b(event_type_t t, void *ctx) { printf("[B] 事件%d\n", t); } int main(void) { int id_a = event_register(EVT_DATA_READY, handler_a, "conn-1"); int id_b = event_register(EVT_DATA_READY, handler_b, NULL); event_register(EVT_TIMEOUT, handler_a, "timer-1"); printf("--- 触发 DATA_READY ---\n"); event_emit(EVT_DATA_READY, NULL); /* 应看到 A 和 B 都被调用 */ printf("--- 注销 B ---\n"); event_unregister(id_b); printf("--- 再次触发 DATA_READY ---\n"); event_emit(EVT_DATA_READY, NULL); /* 只剩 A */ (void)id_a; return 0; }

跑一遍你会看到预期输出。这个测试虽然朴素，但它验证了三件重要的事：多个回调按注册顺序触发、注销后不再触发、不同事件的回调互不干扰。每次我改框架内部实现，都会拿这个小测试回归一遍，比调试真实业务快得多。

4.5 标准库里的回调：qsort 与 signal

框架看完了，回头看看C标准库提供的现成例子。qsort是最经典的回调教学案例：

int cmp_int(const void *a, const void *b) { int x = *(const int *)a; int y = *(const int *)b; return (x > y) - (x < y); /* 稳定的比较写法 */ } int arr[6] = {5, 2, 9, 1, 7, 3}; qsort(arr, 6, sizeof(int), cmp_int);

qsort完全不知道你要排的是什么类型的数据，它只管按照你给的比较规则去搬元素。你给它cmp_int它就是排整数，给它比较字符串的cmp_str它就是排字符串。这就是回调"让通用算法适配任意数据"的威力。

顺带说个细节：return (x > y) - (x < y)这种写法比return x - y更安全，因为当x和y一正一负且数值很大时，x - y可能整型溢出，返回错误的符号。整数排序里这个问题不算大，但如果是long long或者比较的是两组数据，溢出风险就实打实存在了。这个坑我在一个数据量上百万的排序里踩过，结果排出来的顺序偶发错乱，换成上面的写法立刻稳定。

signal也是展示回调的经典例子——它注册一个信号处理函数，等信号到来时被异步调用。这里要特别提醒：信号处理函数里能做的事非常有限，因为它可能在任何指令间隙被打断，调用非异步信号安全的函数可能死锁。工程实践里，信号回调通常只做一件事：把"信号到了"这个事实写进一个volatile sig_atomic_t标志，然后主循环去轮询。这个模式也适用于流量计累计、脉冲计数这类场景——中断里只加计数，复杂计算放到主循环通过回调处理。

5. 常见问题与排查技巧实录

5.1 段错误的几种典型成因

回调相关的段错误，我统计了一下，绝大部分跑不出下面几种。第一种是函数指针为NULL却直接调用。最常见的原因是注册动作发生在触发之后，或者注册失败（池满、参数非法）但返回值没检查。解决办法很直接：触发前判空，注册后检查返回值。第二种是函数指针指向了已经失效的内存，通常是把局部函数指针变量存下来跨作用域用了，或者结构体里的指针被free后没置空。第三种是上下文ctx悬空，这个前面已经重点讲过。第四种是签名不匹配导致的栈错乱，你把一个参数是int的函数注册到了参数是long long的接口上，调用时栈的读取方式就不对了，轻则读到垃圾值，重则崩溃。

排查这类问题的通用顺序是：先打印回调指针地址确认非空且合理，再打印ctx地址，最后在回调入口处打印日志，看看到底是没进来还是进来了才崩。如果崩溃发生在回调内部，那问题往往在ctx指向的数据，用gdb看bt和p *ctx通常一眼就能定位。我强烈建议开发阶段就打开-g -Wall -Wextra，编译器的告警能帮你拦掉相当一部分签名不匹配的问题。

5.2 回调里释放自己的坑

这是一个特别隐蔽、几乎每个写过事件循环的人都栽过的坑：回调在自己执行的过程中，把自己注销甚至释放了。看这段代码：

static void on_event(event_type_t t, void *ctx) { (void)t; conn_t *conn = (conn_t *)ctx; event_unregister(conn->id); /* 回调里注销自己 */ free(conn); /* 甚至把自己相关的资源释放了 */ }

如果框架的emit在调用完回调后，还会去访问这个注册项（比如读它的type做统计），那就访问了已经被注册改动过的数据；更糟的是，如果框架本身持有conn并打算回调结束后使用它，free之后就是彻底的野指针。这个问题在链表版的事件框架里尤其致命，因为节点被释放后遍历指针可能立刻失效。

我的处理原则有两条。第一，框架的遍历逻辑要保证"回调之后不再碰这个注册项"，只要调用前先把需要的数据（比如回调地址、ctx）拷贝到局部变量里再调用，就能规避大部分问题。第二，资源释放要规定由谁负责。如果允许回调里释放，那框架就不能再有任何后续引用；如果不允许，就在文档里明确写死。我一般倾向于后者——让框架统一管理资源生命周期，回调只做业务逻辑，这样心智负担小得多。

5.3 编译告警和类型不匹配

函数指针相关的编译告警，看着烦人是好事，因为它经常帮你提前发现bug。有一个很典型的告警是"赋值给函数指针时类型不兼容"。比如你有个函数返回int，但接口要求返回void，隐式转换在有的编译器上只是警告，运行时可能没问题，但一旦参数列表也不一致就麻烦了。

还有一个新手常问的点：回调函数的参数能不能少写？比如接口要求void cb(int, void*)，我能不能写一个只有int参数的回调？答案是绝对不能。C语言不会帮你补齐参数，运行时框架还是会按两个参数去调用，多出来的那个参数读取到的是栈上的随机值，虽然不崩但行为不确定。所以回调签名必须和接口定义逐字对齐，一个参数都不能少，返回值也一样。

我实际项目里的做法是，在头文件里用typedef统一定义回调类型，所有注册点都用这个类型，编译器就能在赋值时做严格检查。哪个实现签名不对，编译直接报错，用不着等到运行时。

5.4 嵌入式场景下的额外注意事项

嵌入式里用回调，有几条规则是刻在骨子里的。第一，中断服务程序里注册或触发的回调必须极短，只做标志位、入队这类操作，绝不能在里面做浮点运算、动态分配、打印串口。第二，注意可重入和临界区。如果注册表会被中断和主循环同时访问，那么注册、注销、遍历都需要在关中断的情况下做，或者用无锁的单写多读设计。第三，栈空间有限，回调里别递归、别开大数组。

对于流量计累计程序这类典型应用，我的经验是把脉冲计数放在中断里只做g_count++，然后主循环通过回调触发累计计算、滤除抖动、更新显示。这样既保证了计数的实时性，又把复杂逻辑挪出了中断上下文。同类的还有按键回调——按键消抖不适合放中断里做延时，通常是中断置标志、定时器回调里采样判断。

5.5 问题速查表

为了让你排查时更快定位，我把常见问题整理成一张表：

注意：这张表不是让你出问题才看，而是设计阶段就该对着过一遍。我在新项目立项时，会照着类似的表逐条确认"我的方案在这些点上是否安全"，比事后救火省事太多。

6. 我踩坑后沉淀的几条规矩

写了这么多年回调，最后落到几条我一直在用、也推荐给身边人的规矩，都是被实际事故教育出来的。第一条，所有对外暴露的回调类型，一律用typedef定义并加_t后缀，让签名只有一个源头。第二条，所有回调触发点，先判空再调用，这是零成本的保险。第三条，ctx的生命周期永远长于回调可能被触发的整个区间，跨线程、跨事件循环的必须走引用计数。第四条，延迟回调必须提供同步的注销能力，注销返回就意味着"绝对不会再触发"。第五条，中断和信号上下文里的回调只置标志，把复杂逻辑留给主循环或任务回调去处理。这几条看着琐碎，但真到了线上出问题的时候，能帮你省下无数个深夜。

如果你现在正在对着某个回调崩溃点发呆，我建议你按这个顺序查：先确认指针非空，再确认ctx有效，最后确认时序上没有"东西已经被释放但回调还想用"。绝大多数问题都在这三步里。至于把回调用在架构设计上，我的体会是别急着抽接口——先用最直白的函数调用把功能跑通，当你真的发现"同一段逻辑需要被不同场景替换"或者"下层被上层反向依赖"时，再把那个变化点改成回调，那时候你会觉得一切都顺理成章。回调不是用来炫技的，它是用来给变化留出位置的，想清楚这一点，剩下的就是熟练度的事了。