刚入行那会儿翻别人的驱动源码，满屏的xxx_register_callback、on_event、user_data看得人头皮发麻，明明就是一个函数调用，为什么非要绕一圈把函数当参数传进去？后来自己写串口协议解析、写状态机、写 GUI 事件响应，被同一类需求反复摩擦之后才明白：回调函数不是 C 语言的花活，它是解耦这件事在 C 里唯一还算优雅的落地方式。C 语言没有类、没有虚函数、没有闭包，想让底层模块在不知道上层业务的前提下把消息交出去，只能靠函数指针把"待办事项"提前登记好，等到时机成熟再回头调用。这篇就把回调函数从函数指针的语法地基，一路讲到事件注册框架、嵌入式中断分发、异步 IO 状态机，再到我踩过的悬空指针、上下文丢失、类型不匹配这些坑，全部摊开说清楚。不管你是刚学完指针、数组的新手，还是写了几年嵌入式 C 想回头梳理一遍的老手，都能在这篇里找到能直接抄进项目的代码和判断依据。

1. 回调函数到底解决什么问题：先把函数指针这层地基砸实

1.1 从函数指针讲起：回调真正依赖的语法地基

回调这个词听起来玄，拆开就是一句话：把函数的入口地址当作数据存起来，等到合适的时机再通过这个地址去调用它。所以绕不开的第一件事就是函数指针。函数在编译之后会占据一段代码段内存，函数名在大多数表达式里会自动退化成指向该函数首地址的指针，这一点和数组名退化成首地址是同一个道理。区别在于数组元素是同构的，而函数的"形状"由返回类型和参数列表共同决定，所以函数指针的类型必须把这两样都写全。

先看最原始的声明形式，也就是不借助任何 typedef 的裸写法：

int (*fp)(int, int); /* fp 是一个指针，指向“接收两个 int、返回 int”的函数 */

这行的括号是命门。如果写成int *fp(int, int);，含义会彻底变成"一个接收两个 int、返回 int 指针的函数声明"，和指针完全不是一回事。初学者九成以上的混淆都出在这个括号上。我的记忆办法是：先看变量名和谁结合得更紧。(*fp)里 fp 先和星号结合，说明它是指针；指针指向的东西后面跟着(int, int)，说明指向的是函数；最外层的int是那个函数的返回类型。顺着这个顺序读一遍，类型就出来了。

实际项目中没人愿意反复写这种括号，所以通常用 typedef 把类型提出来：

typedef int (*bin_op_t)(int, int); /* 给这类函数指针起个名字 */ bin_op_t add = NULL; /* 现在声明变量像声明 int 一样简单 */

typedef 在这里的价值不只是省字。回调注册接口一旦对外发布，参数类型就是契约的一部分，用 typedef 定义出一个有语义的名字（比如event_handler_t、compare_fn、write_done_cb），调用方一眼就知道该传什么样的函数进去，比裸写一串括号可读性高得多。

提示：函数指针变量本身也是变量，占内存。在 64 位平台上通常是 8 字节，和普通指针一样；在部分 32 位嵌入式平台上可能是 4 字节。判断它是否有效时，和普通指针一样要用== NULL或!= NULL，不要写成if (fp)之外的奇怪判断，更不要拿它去和整数比较。

还有一个容易被忽略的点：函数指针不能指向普通数据，数据指针也不能指向函数。在绝大多数平台上二者虽然都是地址，但语义不同，互相强转再调用属于未定义行为。我见过有人为了"通用"把函数指针塞进int里做哈希表键值，在 x86 上侥幸跑通，换到某些架构上直接跑飞，这类聪明不要耍。

1.2 回调的本质：控制反转与依赖倒置在 C 里的落地

理解了语法，再来看设计意图。假设你要写一个通用的定时器模块，它负责计数、到期判断、任务调度，但它完全不知道"到期之后到底要干什么"——可能是闪一下 LED，可能是发一包数据，也可能是刷一次屏幕。这时候有两种写法。

第一种是把业务写死在定时器里，用switch判断任务类型，然后调用对应的处理函数。问题立刻显现：每加一种新任务，都要回头修改定时器模块本身。模块被反复打开、重新编译、重新测试，任何一次改动都可能把已经稳定的调度逻辑带崩。这就是典型的高层策略依赖低层实现，依赖方向是反的。

第二种是把"到期要做什么"变成一个函数指针，由使用方在注册的时候交进来：

typedef void (*timer_cb_t)(void *arg); int timer_register(int period_ms, timer_cb_t cb, void *arg); void timer_tick(void); /* 底层在合适的时候遍历并调用各回调 */

定时器模块从此只认timer_cb_t这个形状，不认具体函数。依赖方向被掰正了：业务代码依赖定时器模块提供的注册接口，定时器模块不依赖任何具体业务。这就是依赖倒置，而在 C 里实现它的唯一工具就是函数指针。控制权也从"模块内部决定调谁"转移到"注册方决定被调什么"，所以回调常被称为控制反转。

把这个思路放大，你会发现回调几乎无处不在：标准库qsort不关心你怎么比较元素，只要求你给一个比较函数；文件遍历接口不关心你怎么处理每个文件名，只要求你给一个处理函数；网络库不关心收到数据后干什么，只要求你给一个收包回调。凡是"框架管流程、业务管细节"的地方，回调都会出现。

1.3 什么时候该用回调，什么时候反而该绕开

回调好用，但不是万能药。我自己的判断标准有三条，符合其中两条才上回调。

第一，调用时机不确定。如果是顺序执行、调用点固定的逻辑，直接写函数调用就行，套一层函数指针纯属增加阅读成本。回调的价值在于"事情什么时候发生由底层决定"，比如数据到达、定时到期、用户按键，这些都是事件驱动的典型场景。

第二，存在多个可能的实现。只有一个实现而且永远不会有第二个，那回调就是过度设计。但凡是"比较规则""过滤条件""数据源"这类天生会随业务变化的点，用回调就是合适的。

第三，模块边界需要保持稳定。底层库一旦发布，改动成本很高，而它需要服务的上层又五花八门，这时候用回调把变化点隔离出去，能让底层库长时间不动。

反过来，有几种情况我会主动避开回调：调试困难、逻辑简单的短函数；需要返回值而且调用链很深的同步逻辑；以及性能极其敏感的热路径——函数指针调用无法被编译器内联，间接跳转还可能影响分支预测，在高频循环里比直接调用慢是事实。真到了那种场景，要么用宏做编译期"回调"，要么老老实实写死分支。

提示：回调最大的代价不是性能，而是阅读时的跳跃感。你看到cb(arg)这一行，无法从当前文件直接跳到实现，必须去追是谁注册的。所以注册点和实现点最好在命名上形成呼应，比如xxx_register_yyy_handler配on_yyy_event，让人顺着名字就能找回去。

2. 四种主流回调写法与选型对比

2.1 裸函数指针：最轻，也最容易扩展不了

最基础的形态就是直接传函数地址，标准库qsort是最经典的教材级例子：

#include <stdio.h> #include <stdlib.h> static int cmp_int_asc(const void *a, const void *b) { int va = *(const int *)a; int vb = *(const int *)b; return (va > vb) - (va < vb); } int main(void) { int arr[] = {5, 2, 9, 1, 7}; size_t n = sizeof(arr) / sizeof(arr[0]); qsort(arr, n, sizeof(arr[0]), cmp_int_asc); for (size_t i = 0; i < n; ++i) { printf("%d ", arr[i]); } printf("\n"); return 0; }

注意cmp_int_asc里那个(va > vb) - (va < vb)的写法。很多人第一次写比较函数会写成return va - vb;，元素数值小的时候没问题，但两个相差极大的整数相减会溢出，返回值的符号就不可信了。用两次比较相减，结果只可能是 -1、0、1 三种，既避免了溢出，也符合 qsort 对返回值符号的要求。

裸函数指针的优点是零成本、语义清晰。缺点也很致命：没有地方挂上下文。如果比较逻辑需要依赖一个外部参数，比如"按某个基准值排序"，而这个基准值又不能在编译期确定，裸函数指针就只能靠全局变量传参。全局变量一多，重入性和线程安全就全没了。这就引出了第二种写法。

2.2 带上下文指针的注册式回调：嵌入式里的工业标准

解决传参问题的主流做法，是在回调类型里加一个void *上下文参数，同时把回调函数本身也存进一个注册表：

typedef void (*event_handler_t)(int event_id, void *ctx); #define MAX_HANDLERS 8 typedef struct { int event_id; event_handler_t handler; void *ctx; } handler_slot_t; static handler_slot_t g_slots[MAX_HANDLERS]; static int g_slot_count = 0; int event_on(int event_id, event_handler_t handler, void *ctx) { if (handler == NULL || g_slot_count >= MAX_HANDLERS) { return -1; /* 参数非法或容量已满 */ } g_slots[g_slot_count].event_id = event_id; g_slots[g_slot_count].handler = handler; g_slots[g_slot_count].ctx = ctx; g_slot_count++; return 0; } void event_emit(int event_id, int payload) { for (int i = 0; i < g_slot_count; ++i) { if (g_slots[i].event_id == event_id) { g_slots[i].handler(payload, g_slots[i].ctx); } } }

上层的使用方式变得很自然，业务状态可以塞进一个结构体，把地址当ctx传进去，回调里再转回来：

typedef struct { const char *name; int counter; } module_t; static void on_tick(int payload, void *ctx) { module_t *m = (module_t *)ctx; /* 转回具体类型 */ m->counter += payload; printf("[%s] counter=%d\n", m->name, m->counter); }

ctx用void *是刻意的取舍。C 没有泛型，只能用无类型指针换取通用性，代价是类型安全由使用者自己保证：传入什么类型，回调里就必须转回什么类型，转错了编译器不会报错，运行时行为不可预测。

注意：void *和函数指针之间不要互相强转。有些人为了省事，把函数地址也塞进void *的 ctx 里，这在不同平台上的可移植性存疑。需要区分"回调 + 上下文"和"多个回调选一个"时，用两个独立参数或一个联合体，比混在一个指针里安全得多。

event_emit里那个payload参数我特意用了裸int。真实项目里通常会把它换成const void *加长度，或者一个统一的event_msg_t结构体，让事件携带的数据规格统一。这里先用 int 是为了让结构清楚，扩展的时候改一处类型定义即可。

2.3 函数指针数组：把 if-else 链变成查表

当"回调"的分支是有限枚举、数量固定的时候，函数指针数组比注册表更高效，也比switch更易维护。命令行解析是最典型的场景：

typedef int (*cmd_fn)(const char *arg); static int cmd_help(const char *arg) { (void)arg; printf("help/set/get\n"); return 0; } static int cmd_set (const char *arg) { printf("set %s\n", arg ? arg : ""); return 0; } static int cmd_get (const char *arg) { (void)arg; printf("get\n"); return 0; } typedef struct { const char *name; cmd_fn fn; const char *help; } cmd_entry_t; static const cmd_entry_t g_cmds[] = { {"help", cmd_help, "显示可用命令"}, {"set", cmd_set, "写入参数"}, {"get", cmd_get, "读取参数"}, }; static int dispatch(const char *name, const char *arg) { size_t n = sizeof(g_cmds) / sizeof(g_cmds[0]); for (size_t i = 0; i < n; ++i) { if (strcmp(g_cmds[i].name, name) == 0) { return g_cmds[i].fn(arg); } } printf("unknown command: %s\n", name); return -1; }

这套写法的好处很实在：新增命令只加一行表项，dispatch一个字都不用改；help信息自然跟着表走，不会出现"加了功能忘了改帮助"的情况；整个表在只读数据段，改不了也不该改。数组长度用sizeof除出来，不写魔法数字，加减表项时不会漏改上限。

2.4 结构体打包回调：C 里的"接口"与虚表雏形

再往上一步，就是把一组回调打包进结构体，用它来模拟面向对象里的接口。驱动层最常见的做法是把 read、write、ioctl 三个回调放进一个操作集结构体：

typedef struct device device_t; typedef struct { int (*open)(device_t *dev); int (*read)(device_t *dev, void *buf, int len); int (*write)(device_t *dev, const void *buf, int len); int (*close)(device_t *dev); } device_ops_t; struct device { const char *name; const device_ops_t *ops; /* 指向某个具体实现的操作集 */ void *priv; /* 具体实现自己的私有数据 */ };

调用方只用dev->ops->write(dev, buf, len)，完全不知道底下是串口、文件还是内存缓冲区。想换实现，换一个ops指向就行。这个结构就是 C 里最朴素的虚函数表：函数指针数组负责分派，私有数据指针负责保存状态。配合priv，每个实例还能有自己独立的数据，不会有全局变量那种互相干扰的问题。

这四种写法不是替代关系，而是递进的工具箱：简单比较用裸函数指针，需要传状态用带 ctx 的注册，分支固定用数组查表，需要多实例多实现用操作集结构体。选型的核心就一句话——看你需不需要保存"这个回调属于谁"的状态。

3. 手写一个能进项目的事件回调框架

3.1 先定接口：把易变的部分留给调用方

框架设计的第一步永远是划边界。我要做的是一个极小的事件系统，需求有这么几条：支持多个订阅者订阅同一事件；发送事件时可以携带一小段数据；订阅者可以随时退订；所有内存都由静态数组提供，不依赖堆。为什么不用malloc？因为嵌入式环境里堆的碎片化是最难查的一类故障，能用静态数组解决的就不要引入动态分配。

接口定成这样：

typedef void (*ev_cb_t)(int event_id, const void *data, int len, void *ctx); int ev_subscribe(int event_id, ev_cb_t cb, void *ctx); int ev_unsubscribe(int event_id, ev_cb_t cb); void ev_publish(int event_id, const void *data, int len);

四个参数的回调看起来有点长，但每个都有存在理由：event_id让同一个处理函数能订阅多个事件；data和len成对出现，是为了支持二进制数据，不能用strlen去猜长度；ctx是调用方的私有状态。

注意：这里把长度和指针分开传，而不是只传一个字符串指针，是有意的。二进制数据里完全可能包含 0x00，一旦有人图省事用strlen或strstr去处理，遇到第一个 0 字节就截断了，后面的内容全部丢失，而且不报错。凡是可能承载二进制的缓冲区，长度必须显式传递。

3.2 核心实现：注册、注销与派发的三段逻辑

完整实现如下，注释里写清楚每一步在防什么：

#include <stdio.h> #include <string.h> typedef void (*ev_cb_t)(int event_id, const void *data, int len, void *ctx); #define MAX_SUBS 16 typedef struct { int event_id; ev_cb_t cb; void *ctx; int used; } sub_t; static sub_t g_subs[MAX_SUBS]; int ev_subscribe(int event_id, ev_cb_t cb, void *ctx) { if (cb == NULL) { return -1; } /* 先找空位，注意不要在遍历中做插入，避免下标混乱 */ for (int i = 0; i < MAX_SUBS; ++i) { if (!g_subs[i].used) { g_subs[i].event_id = event_id; g_subs[i].cb = cb; g_subs[i].ctx = ctx; g_subs[i].used = 1; return 0; } } return -2; /* 容量已满 */ } int ev_unsubscribe(int event_id, ev_cb_t cb) { for (int i = 0; i < MAX_SUBS; ++i) { if (g_subs[i].used && g_subs[i].event_id == event_id && g_subs[i].cb == cb) { g_subs[i].used = 0; g_subs[i].cb = NULL; g_subs[i].ctx = NULL; return 0; } } return -1; /* 没找到对应的订阅 */ } void ev_publish(int event_id, const void *data, int len) { for (int i = 0; i < MAX_SUBS; ++i) { if (g_subs[i].used && g_subs[i].event_id == event_id) { g_subs[i].cb(event_id, data, len, g_subs[i].ctx); } } }

三个函数里各有一处值得展开。

ev_subscribe用的是未占用的槽位标记法而不是紧凑数组。删掉一个订阅者之后，不把后面的元素前移，只把used置 0。这样做牺牲了几个槽位的空间，换来的是"订阅者手里持有的下标永远有效"。如果用紧凑数组加移位，任何一次注销都会让其他订阅者的下标失效，后续派发就会错位调用到别人的回调上，这种 bug 极难定位。

ev_unsubscribe里对used、event_id、cb三个条件都做了判断。只比cb是不够的，同一个处理函数完全可能订阅了两个不同事件，只按函数地址找到的是另一个订阅项，取消掉的就不是用户想取消的那个。

ev_publish有一个隐藏风险：如果在回调内部调用了ev_unsubscribe或ev_subscribe，就会在遍历过程中修改g_subs。当前实现里这种修改是"就地生效"的，可能影响本次循环后续的判断。稳妥做法是先拷贝一份待调用列表再逐个回调，或者加一个"正在派发"的标志位，把派发期间的增删操作延迟到派发结束后统一处理。

3.3 跑一遍验证：从订阅到退订的完整链路

写一小段测试把三条路径都覆盖到：

typedef struct { const char *tag; int count; } consumer_t; static void consumer_on_data(int event_id, const void *data, int len, void *ctx) { consumer_t *c = (consumer_t *)ctx; c->count++; printf("[%s] event=%d len=%d count=%d\n", c->tag, event_id, len, c->count); } int main(void) { consumer_t a = {"A", 0}; consumer_t b = {"B", 0}; ev_subscribe(100, consumer_on_data, &a); ev_subscribe(100, consumer_on_data, &b); ev_subscribe(200, consumer_on_data, &a); const char payload[] = {0x01, 0x00, 0x02, 0x03}; ev_publish(100, payload, (int)sizeof(payload)); /* A、B 各收到一次 */ ev_publish(200, NULL, 0); /* 只有 A 收到 */ ev_unsubscribe(100, consumer_on_data); /* 两个都退订 */ ev_publish(100, payload, (int)sizeof(payload)); /* 没人收到 */ ev_unsubscribe(200, consumer_on_data); return 0; }

编译方式很朴素，把 GCC 的告警档位开高一点：

gcc -Wall -Wextra -O1 -g event.c -o event ./event

-Wall -Wextra这两个开关一定要加。回调相关的代码里最容易出的问题就是参数类型不匹配和未使用参数，这两个开关能把绝大多数低级错误在编译期拦下来。示例里cmd_help里写(void)arg;就是为了明确表达"这个参数我用不上"，而不是忘了写。

预期输出是 A、B 各打印一次 count=1，然后 A 打印 count=2，退订之后再发事件不再有任何输出。如果退订之后仍然有输出，说明匹配条件写漏了；如果 A 的 count 在第二次事件时变成 1 而不是 2，说明ctx没正确回传，值得逐行对一遍。

3.4 几个和参数、内存相关的实测量

在 64 位 Linux 上用 GCC 打印一下相关尺寸，心里有个数：

printf("sizeof(void*) = %zu\n", sizeof(void *)); printf("sizeof(ev_cb_t) = %zu\n", sizeof(ev_cb_t)); printf("sizeof(sub_t) = %zu\n", sizeof(sub_t));

我这边的结果是void *8 字节，函数指针 8 字节，sub_t因为int后面有对齐填充是 24 字节。三个数字背后的含义值得说清楚：16 个订阅槽就是 16×24 约 384 字节静态内存，一个很小的进程完全负担得起。如果是 32 位 MCU，指针降到 4 字节，sub_t大约是 16 字节，64 个槽位也才 1KB 出头。先算清楚内存账再决定槽位上限，比事后发现 RAM 不够再回头改结构体划算得多。

对齐这件事在回调结构体里也藏了坑。如果将来把event_id换成char，结构体成员顺序不变的话，中间会因为对齐多出几个填充字节，整体大小反而不减。按"从大到小"排成员通常能压掉填充：指针对齐要求最高，int次之。当然这个优化在槽位只有几十个的时候意义不大，不必为了省几十字节牺牲可读性。

4. 嵌入式与系统编程中的回调实战

4.1 中断里的回调：为什么必须"快进快出"

嵌入式的按键扫描、串口接收、定时器溢出，几乎都靠中断触发，而中断服务函数本身能做的事极其有限：不能长时间阻塞、不能随便用浮点、很多平台上不能直接调用可能重入的函数。于是通用做法是让中断只做最轻的一件事——置个标志或存一个字节，然后由主循环来派发回调。

static volatile int g_tick_flag = 0; void SysTick_Handler(void) /* 中断上下文 */ { g_tick_flag = 1; /* 只做标记，绝不调用业务回调 */ }

主循环里再把它转化成事件：

static void tick_on_loop(void) { if (g_tick_flag) { g_tick_flag = 0; ev_publish(300, NULL, 0); /* 在任务上下文里安全地派发 */ } }

这个"中断打标、主循环派发"的模型是有意为之。业务回调里可能调printf、可能操作 SPI、可能等锁，这些操作在中断上下文里的行为要么未定义，要么把别的中断延迟压得很难看。把回调调用点从中断上下文搬到任务上下文，等于给所有订阅者提供了一个安全屋。代价是响应延迟从一个中断周期变成一次主循环轮询的间隔，绝大多数场景下这点延迟可以忽略。

注意：g_tick_flag这类被中断和主循环同时访问的变量必须加volatile。不加的话，编译器可能认为主循环里的if (g_tick_flag)在循环中没有被修改过，直接把它优化成"只读一次"，于是标志永远保持第一次读到的值，按键或定时事件全部失灵。这类问题在开优化之后才出现，release 版本翻车、debug 版本正常，是典型的优化相关故障。

4.2 回调 + 状态机：异步流程的可读写法

异步接收一段变长协议的时候，回调的真正价值是让状态推进逻辑集中在一处，而不用把解析代码揉进主循环。典型结构是每收到一个字节就喂给状态机：

typedef enum { ST_HEAD, ST_LEN, ST_BODY, ST_TAIL } parse_state_t; typedef struct { parse_state_t state; int want; int got; unsigned char body[64]; void (*on_frame)(const unsigned char *buf, int len, void *ctx); void *ctx; } parser_t; static void parser_feed(parser_t *p, unsigned char byte) { switch (p->state) { case ST_HEAD: if (byte == 0xAA) { p->state = ST_LEN; } break; case ST_LEN: p->want = byte; p->got = 0; p->state = (byte > 0 && byte <= (int)sizeof(p->body)) ? ST_BODY : ST_HEAD; break; case ST_BODY: p->body[p->got++] = byte; if (p->got >= p->want) { p->state = ST_TAIL; } break; case ST_TAIL: if (byte == 0x55 && p->on_frame) { p->on_frame(p->body, p->got, p->ctx); /* 只有完整帧才回调 */ } p->state = ST_HEAD; break; } }

这段代码里有几个刻意的设计。ST_LEN里对长度做了范围检查，因为长度字段来自外部输入，如果直接信它，一个伪造的超长长度就会让p->body越界写入，把栈或堆上的其他数据冲掉——这是缓冲区溢出最经典的入口。长度非法时直接退回ST_HEAD重新寻找帧头，而不是继续往缓冲区里写。只有收到完整帧头和帧尾，才触发一次on_frame回调，把"解析正确"和"使用数据"两件事彻底分开：解析器不需要知道这条帧是温度还是电量，订阅者也不需要知道字段是怎么切出来的。

状态迁移的每条路径都显式赋值p->state，没有依赖默认分支。这样做的另一个好处是，将来加一个转义字符处理只需要插入一个状态，原有迁移不受影响。

4.3 回调生命周期管理：悬空指针是怎么产生的

回调相关的崩溃，绝大多数不是回调本身写错了，而是回调被调用时，它依赖的数据已经不在了。常见场景有两种。

第一种是对象先于回调被销毁。比如创建了一个连接对象，注册了接收回调，连接关闭后对象被释放，但注册表里的记录没被清掉。下一个数据包到达时，框架照旧调用回调，回调里访问已经释放的ctx，读到的可能是任意内容。解决办法有两个方向：要么在销毁对象前强制注销所有相关回调，要么在回调里加一层有效性校验。前者更干净，后者更兜底。我的习惯是销毁函数里第一件事就是遍历注册表，把所有ctx等于本对象地址的订阅全部清掉，然后再释放内存。

提示：注销时机这件事最好写进对象的生命周期文档里，明确"销毁前必须注销"。如果做不到强制，就在注册接口里返回一个句柄，销毁时用句柄统一注销，比按函数指针反查可靠得多。

第二种是回调里访问了超出生命周期的栈内存。比如把某个局部数组的地址作为ctx注册出去，函数返回之后这块栈空间就被复用了。这类问题在某些编译器下会给出 "address of local variable returned" 的警告，但经过一层void *转换之后警告常常消失，非常隐蔽。凡是作为ctx长期保存的地址，来源必须是静态存储区、全局变量或堆上分配且明确管理生命周期的对象。

static void bad_register(void) { int local_state = 0; ev_subscribe(400, some_cb, &local_state); /* 错误：local_state 很快失效 */ }

上面这段就是典型反例，函数一返回注册表里就存了一个悬空地址，后面每次派发都在读垃圾数据。

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

5.1 回调相关故障速查表

下面这张表是我这些年实际遇到过的问题，按出现频率从高到低排。

表里有两项值得单独说。浮点相等判断这条在回调里出现得特别多，因为传感器数据通过回调上报之后，很多人习惯性地写if (value == 25.0)来判断温度是否达标。IEEE 754 浮点是二进制近似表示，0.1 这类十进制小数无法精确存储，运算几轮之后误差就出来了，相等判断几乎必然失败。正确做法是fabs(a - b) < 1e-6这种容差比较，容差大小按数据量级选。

注销后仍被调用这条的隐蔽性最高。表现是"我已经取消订阅了，为什么还在处理数据"，本质往往是注册表里存在两份记录，或者匹配条件只比了函数地址没比事件号。加上used标记和三元匹配之后这类问题基本绝迹。

5.2 五个我反复用到的避坑习惯

第一个习惯是注册接口一律返回状态码。返回 int，成功返回 0，参数非法返回负值，容量满返回另一个负值。有人觉得回调注册不会失败，但容量满这件事在嵌入式里非常现实，悄悄失败会导致某个功能莫名其妙不工作，还不如在初始化阶段就把错误打出来。

第二个习惯是回调里绝不调用可能阻塞的函数。虽然当前示例是单线程派发，但真实项目里回调可能在定时器线程、IO 线程里被调用，回调里如果去拿一把会被别的路径持有的锁，就是死锁的完美配方。需要耗时操作时，回调只负责把数据拷进队列，让工作线程去处理。

第三个习惯是保存数据不要保存指针。回调收到const void *data, int len之后，如果要留着以后用，一定按长度memcpy一份，绝不能直接存这个指针。这个缓冲区很可能是底层复用的临时区，下一次事件就会把内容覆盖掉。我早期写串口解析时就在这里栽过，收到的帧看起来"有时对有时错"，查了两天才发现是缓冲区复用。

第四个习惯是用编译期断言锁死回调签名。接口一旦对外，改动签名就是破坏性变更，可以在头文件里加一句静态断言，让编译期直接报错而不是运行期行为异常：

#define STATIC_ASSERT(cond, name) typedef char static_assert_##name[(cond) ? 1 : -1] STATIC_ASSERT(sizeof(ev_cb_t) == sizeof(void (*)(void)), ev_cb_size);

第五个习惯是调试时给每个回调加日志埋点，但只在开发版本开启。方法是用条件编译包一层：

#ifdef CB_TRACE #define CB_LOG(fmt, ...) printf("[cb] " fmt "\n", ##__VA_ARGS__) #else #define CB_LOG(fmt, ...) ((void)0) #endif

发布版本里CB_LOG展开成一条空语句，零开销；开发版本打开-DCB_TRACE就能看到每次注册和派发的顺序。回调问题的排查难点在于"谁在什么时候注册了谁"，有这条日志，调用顺序一目了然。

5.3 调试器里追回调的几个实用招

回调出问题时，打印日志之外还有几个更直接的手段。

第一个是在派发点打断点并打印调用栈。GDB 里在ev_publish的调用处下断点，命中之后bt一下就能看到是谁触发的事件，p g_subs[i]能看到当前槽位的完整内容。这比在回调函数里打断点有效，因为回调可能被多个入口触发，而从派发点看更接近源头。

第二个是把函数指针打印出来做比对。注册和派发两端都把cb的地址打出来，如果两端地址不一样，说明注册的那份记录和派发的这份记录根本不是同一个槽位，问题就锁定在注册表管理上。

CB_LOG("subscribe cb=%p ctx=%p event=%d", (void *)cb, ctx, event_id); CB_LOG("dispatch cb=%p ctx=%p event=%d", (void *)g_subs[i].cb, g_subs[i].ctx, event_id);

注意打印函数指针时强转成void *，用%p输出。直接传函数指针给变参函数在部分平台上会触发告警，转一下更稳。

第三个是用地址消毒器先跑一遍。GCC 和 Clang 都支持-fsanitize=address,undefined，编译时加上这两个开关，悬空指针访问、越界读写、有符号溢出这些问题会直接带着调用栈报出来。回调框架里最容易出的就是ctx生命周期和缓冲区长度这两类问题，ASan 基本一抓一个准。

gcc -Wall -Wextra -g \ -fsanitize=address,undefined \ -fno-omit-frame-pointer \ event.c -o event_asan

注意：ASan 会显著增加内存占用和运行时开销，只能在开发调试阶段开，不能带进生产构建。它的价值在于把那些"偶尔崩一次、复现困难"的问题变成必现，配合调用栈定位到具体行，比靠打印猜快得多。

我个人的经验是，回调相关的 bug 有八成以上能归到两类：指针为空和生命周期错位。前者加判空就能防住，后者靠制度——注册和注销必须成对出现，销毁对象必须清注册表，长期保存的数据必须拷贝。把这两条变成写代码时的肌肉记忆，回调这部分基本就不会再给你添麻烦了。至于进阶方向，可以试着把定时器、事件注册、状态机三样拼起来做一个小的任务调度器，用回调驱动各个任务，那时候你会对"框架管流程、业务管细节"这句话有完全不一样的理解。