14、函数指针：回调函数的声明与调用规范

函数指针这东西，说实话，很多C语言开发者学了三年五年还是用不利索。我刚开始做嵌入式那会儿，也觉得这东西可有可无——直到有一次，我被一个按键驱动折磨了整整两天。

那是个多按键的交互设备，每个按键按下后的行为都不一样。我一开始用switch-case，写了三百多行，改一次需求就要改整个函数。后来老工程师看了一眼，说：「你试试回调函数。」嗯，从那以后，我再也没写过那种硬编码的按键处理了。

14.1 函数指针的本质

说白了，函数指针就是一个地址。它指向代码区里某段可执行代码的入口。你想想看，变量有地址，函数当然也有地址。

声明一个函数指针，语法上有点绕。我个人的记忆方法是：把函数名换成指针变量名，前面加个星号，整体加个括号。

// 普通函数声明
void my_handler(int event);

// 对应的函数指针声明
void (*handler_ptr)(int event);

那个括号不能省。为什么？因为 void *handler_ptr(int event) 会被解析成一个返回 void* 的函数，而不是一个指针。C语言的运算符优先级，坑过不少人。

14.2 回调函数的典型声明模式

回调函数，本质上就是把函数指针当作参数传给另一个函数。被调用的函数在合适的时机，通过这个指针去调用你传进来的函数。

我习惯用 typedef 给函数指针起个名字，这样代码读起来舒服很多：

// 定义回调函数类型
typedef void (*callback_t)(int event_id, void *user_data);

// 注册回调的函数
void register_callback(callback_t cb, void *user_data);

// 使用示例
void my_event_handler(int event_id, void *user_data) {
    // 处理事件
}

register_callback(my_event_handler, NULL);

你看，这样声明清晰多了。我在项目中遇到过不少同事直接写函数指针参数，那声明长得能绕晕人。用 typedef 包装一下，大家都轻松。

14.3 调用规范与注意事项

调用回调函数之前，一定要判空。这是血的教训。我曾经接手过一个项目，回调函数指针没初始化就被调用了，结果程序直接跑飞到异常中断里。

// 安全的调用方式
if (callback != NULL) {
    callback(event_id, user_data);
} else {
    // 记录错误或使用默认处理
}

还有一点要注意：回调函数的执行上下文。如果回调是在中断服务函数里被调用的，那回调函数本身就不能做太多事情——不能阻塞、不能调用可能引起调度的函数、不能操作共享资源而不加保护。

14.4 回调函数的典型应用场景

嵌入式开发中，回调函数最常见的几个地方：

• 定时器超时处理：定时器到期后，调用注册的回调函数
• 按键事件处理：按键按下、释放、长按等事件分发
• 通信协议栈：收到完整数据帧后，回调上层处理函数
• 状态机跳转：状态进入/退出时执行特定动作

我举个例子，一个简单的定时器回调框架：

typedef struct {
    uint32_t period;           // 定时周期（毫秒）
    uint32_t remaining;        // 剩余时间
    timer_callback_t callback; // 超时回调
    void *user_data;           // 用户数据
    bool active;               // 是否激活
} timer_t;

void timer_tick(timer_t *timers, int count) {
    for (int i = 0; i < count; i++) {
        if (!timers[i].active) continue;
        
        if (--timers[i].remaining == 0) {
            timers[i].remaining = timers[i].period;
            if (timers[i].callback != NULL) {
                timers[i].callback(timers[i].user_data);
            }
        }
    }
}

这个模式我在好几个项目里都用过。简单、可靠、容易扩展。

14.5 函数指针数组与查表法

有时候，回调函数不止一个。比如一个设备有多个命令码，每个命令码对应一个处理函数。这时候用函数指针数组，比switch-case优雅得多。

// 定义命令处理函数类型
typedef int (*cmd_handler_t)(const uint8_t *data, uint16_t len);

// 命令处理函数表
typedef struct {
    uint8_t cmd_code;
    cmd_handler_t handler;
} cmd_entry_t;

// 查表执行
int execute_command(uint8_t cmd, const uint8_t *data, uint16_t len) {
    static const cmd_entry_t cmd_table[] = {
        {0x01, handle_read_status},
        {0x02, handle_write_config},
        {0x03, handle_reset_device},
        {0xFF, handle_unknown_cmd}
    };
    
    for (int i = 0; i < sizeof(cmd_table)/sizeof(cmd_table[0]); i++) {
        if (cmd_table[i].cmd_code == cmd) {
            return cmd_table[i].handler(data, len);
        }
    }
    return -1; // 未找到
}

这种写法，新增一个命令只需要加一行表项，不用改任何逻辑代码。我在做通信协议栈的时候特别喜欢用这个模式。

14.6 回调函数的生命周期管理

嗯，这里要特别说一下。回调函数注册了，什么时候注销？如果不注销，会不会出问题？

答案是：一定会。如果注册回调的模块已经销毁了，但回调函数指针还在，一旦被调用，就是典型的「悬空指针」问题。

// 注册
int register_event_handler(event_id_t id, callback_t cb, void *data);

// 注销
void unregister_event_handler(event_id_t id);

// 模块销毁时
void my_module_deinit(void) {
    for (int i = 0; i < MAX_EVENTS; i++) {
        unregister_event_handler(i);
    }
    // 其他清理工作...
}

14.7 回调函数的性能考量

回调函数有性能开销吗？有，但通常可以忽略。一次函数指针的间接调用，比直接函数调用多一次内存访问。在绝大多数嵌入式场景下，这不是瓶颈。

但有一种情况要注意：高频调用的回调。比如一个每秒触发10000次的定时器回调，如果每次都要判空、查表、间接调用，累积起来还是有影响的。

我个人的建议是：

• 普通场景（每秒几百次以下）：放心用回调，代码可维护性更重要
• 高频场景（每秒几千次以上）：考虑用直接函数调用，或者用宏展开
• 中断场景：回调函数要短小精悍，最好只设置一个标志位

14.8 回调函数的可移植性

不同架构下，函数指针的调用约定可能不同。比如有些MCU上，函数指针可能指向不同的内存区域（Flash、RAM），调用方式有细微差别。

我踩过的一个坑：在某款ARM Cortex-M0芯片上，函数指针如果指向RAM中的代码（比如从Flash拷贝到RAM的补丁函数），调用时需要用特殊的指令。当时查了两天才找到原因。

所以，如果你在写跨平台的代码，建议：

• 统一使用标准C的函数指针语法
• 不要假设函数指针的大小（用 sizeof 去确认）
• 不要对函数指针做强制类型转换（除非你非常清楚你在做什么）

回调函数用好了，代码的灵活性和可维护性会上一个台阶。用不好，那就是给自己挖坑。我个人觉得，掌握回调函数是C语言从「入门」到「进阶」的一道分水岭。你想想看，一个函数能把自己的一部分行为交给外部来定义，这本身就是一种很优雅的设计思想。

嗯，关于回调函数，今天就聊这么多。记住那几个关键点：声明用typedef、调用前判空、注意生命周期。做到这三点，你就能避开我当年踩过的那些坑了。