函数指针本质与四大实战场景：从内存地址到回调、状态机、插件与多态

1. 为什么函数指针不是“高级技巧”，而是C/C++程序员的呼吸方式

你第一次在代码里看到int (*func_ptr)(int, char*)这串字符时，是不是下意识缩了下脖子？括号套括号，星号夹中间，像一道没给括号的数学题。很多刚学完数组指针、结构体指针的朋友，到这里突然卡住——“指针我懂，函数我也懂，可函数指针……它到底指向什么？又怎么用？”

其实，函数指针根本不是什么炫技工具。它是C语言底层机制最诚实的镜像：函数名在编译后就是一段内存地址，和变量地址没有本质区别。你声明void print_hello()，编译器就把它翻译成“从0x4005a0这个地址开始执行若干条机器指令”；而void (*p)() = print_hello;不过是把这串地址存进一个变量里——就像把门牌号抄在便签纸上，而不是天天跑过去敲门。

我带过的某高校嵌入式实训班里，A同学写中断服务程序时死活搞不定回调注册，反复问：“为什么不能直接传函数名？非要加个取地址符&？”——他卡在概念层，以为函数是“动作”，忘了编译器眼里它只是“数据块”。直到我们用GDB在汇编层单步跟踪：call print_hello指令实际执行的是call *0x4005a0，他才拍大腿：“哦！原来函数名早被替换成地址了！”

这就是函数指针存在的底层逻辑：它让“执行逻辑”本身变成可传递、可存储、可决策的一等公民。你在Linux内核里看到的struct file_operations，Qt里的信号槽连接，FreeRTOS的任务函数注册，甚至Python的functools.partial底层实现——全靠这一招。它不解决某个具体业务问题，而是为所有需要“动态决定执行谁”的场景提供基础设施。

适合谁读？如果你正在写驱动、做嵌入式开发、维护大型C/C++项目，或者想真正看懂STL源码里std::function的模板展开过程，那函数指针不是选修课，是必修的呼吸训练。哪怕你主攻Python或JavaScript，理解它也能让你看清“高阶函数”“闭包”这些概念在底层如何落地——毕竟V8引擎和CPython解释器，最终都得靠函数指针调度原生函数。

2. 函数指针的本质解构：从语法迷雾到内存真相

2.1 语法糖衣下的三重真相

初学者常被int (*p)(int, char*)的写法吓退，但拆开看，它只说三件事：

1. p是一个变量名（和int a;里的a地位完全相同）
2. *p表示p存储的是地址（和int *p;的*含义一致）
3. (int, char*)描述这个地址指向的函数“长什么样”（参数类型、数量、返回值）

提示：int *p读作“p是一个指向int的指针”，那么int (*p)(int, char*)就该读作“p是一个指向‘接受int和char*参数、返回int’的函数的指针”。括号强制*绑定到p，而非绑定到int——这是唯一需要刻意记忆的语法规则。

我们用生活类比：假设你要租仓库，合同里写“承租方需提供能装下10台服务器、带双路供电、温控精度±0.5℃的机柜”。这里“10台服务器”是参数，“双路供电”是约束，“±0.5℃”是返回要求。函数指针声明就是在签这份“机柜规格合同”，而函数定义就是按合同建好机柜。p不是机柜本身，是贴在机柜门上的标签纸，上面写着“此处符合XX规格”。

2.2 内存布局实证：函数地址真的能当普通指针用吗？

很多人怀疑：“函数地址和数据地址混用，不会出事？”——我们用真实代码验证：

#include <stdio.h> #include <stdint.h> int add(int a, int b) { return a + b; } int sub(int a, int b) { return a - b; } int main() { // 获取函数地址（不加&也合法，函数名自动转地址） void *addr1 = (void*)add; void *addr2 = (void*)sub; printf("add 地址: %p\n", addr1); printf("sub 地址: %p\n", addr2); printf("地址差值: %ld 字节\n", (uintptr_t)addr2 - (uintptr_t)addr1); // 关键验证：把函数地址当普通指针存进int数组（仅用于演示！） uintptr_t func_addrs[2] = {(uintptr_t)add, (uintptr_t)sub}; int (*fp)(int,int) = (int(*)(int,int))func_addrs[0]; printf("通过uintptr_t还原调用: %d\n", fp(10, 3)); // 输出13 return 0; }

实测结果（x86_64 Linux）：

add 地址: 0x55e9b7f05149 sub 地址: 0x55e9b7f0515a 地址差值: 17 字节 通过uintptr_t还原调用: 13

看到没？函数地址能存进void*、能转成uintptr_t、能参与算术运算——它和数据地址共享同一套虚拟内存寻址空间。现代操作系统中，代码段（.text）和数据段（.data）虽有读写执行权限隔离，但地址编号体系完全统一。这也是为什么dlsym()能返回void*，你却能安全地强转成函数指针——因为底层就是同一套地址总线。

2.3 类型系统铁律：为什么int (*)(int)和int (*)(int, int)绝不兼容？

C标准明确规定：函数指针类型由返回值类型、参数类型列表（含数量）、是否可变参数共同决定，缺一不可。我们用反例说明：

int calc1(int a) { return a * 2; } int calc2(int a, int b) { return a + b; } int main() { int (*p1)(int) = calc1; // ✅ 正确：类型完全匹配 int (*p2)(int, int) = calc2; // ✅ 正确 // ❌ 危险操作：强行赋值（编译警告，运行崩溃） // int (*p3)(int, int) = calc1; // warning: assignment from incompatible pointer type // 如果硬要绕过编译器（不推荐！） int (*p4)(int, int) = (int(*)(int,int))calc1; printf("%d\n", p4(5, 0)); // 可能输出10，也可能段错误！ return 0; }

为什么危险？因为调用约定（calling convention）在起作用。x86-64 System V ABI规定：前6个整数参数用%rdi, %rsi, %rdx, %rcx, %r8, %r9寄存器传递。calc1只读%rdi，calc2会读%rdi和%rsi。当你用p4(5,0)调用calc1时，0被写进%rsi，但calc1根本不看它——看似没事。但如果calc1内部有printf等变参函数，它会去栈上找参数，而%rsi的值可能污染栈帧，导致不可预测行为。

注意：这种类型转换在嵌入式裸机开发中偶尔出现（如启动代码跳转），但必须配合汇编级验证。在应用层开发中，任何绕过类型检查的函数指针赋值，都是在埋雷。

3. 函数指针的四大核心战场与实操范式

3.1 场景一：回调机制——让库代码“听你指挥”

回调是函数指针最经典的应用。想象你写了一个通用排序函数，但元素比较规则由用户决定——比如对学生成绩按总分排，对商品按价格排。传统做法是写N个排序函数，而回调只需一个：

// 通用冒泡排序（支持任意类型+任意比较逻辑） void bubble_sort(void *base, size_t nmemb, size_t size, int (*compar)(const void *, const void *)) { char *arr = (char*)base; for (size_t i = 0; i < nmemb - 1; i++) { for (size_t j = 0; j < nmemb - 1 - i; j++) { char *a = arr + j * size; char *b = arr + (j + 1) * size; if (compar(a, b) > 0) { // 交换内存块（标准库qsort也这么干） for (size_t k = 0; k < size; k++) { char tmp = a[k]; a[k] = b[k]; b[k] = tmp; } } } } } // 用户自定义比较函数：按int升序 int cmp_int_asc(const void *a, const void *b) { return *(int*)a - *(int*)b; } // 用户自定义比较函数：按字符串长度降序 int cmp_str_len_desc(const void *a, const void *b) { const char *s1 = *(const char**)a; const char *s2 = *(const char**)b; return strlen(s2) - strlen(s1); // 注意：降序所以s2-s1 } int main() { int nums[] = {3, 1, 4, 1, 5}; bubble_sort(nums, 5, sizeof(int), cmp_int_asc); // nums变为{1,1,3,4,5} const char *words[] = {"hi", "hello", "a"}; bubble_sort(words, 3, sizeof(char*), cmp_str_len_desc); // words变为{"hello","hi","a"} return 0; }

关键点解析：

• compar参数是函数指针类型，声明为int (*)(const void*, const void*)，表示“接受两个void*、返回int的函数”
• qsort标准库正是这样设计的，所以你的自定义比较函数能无缝接入
• 实操心得：比较函数返回值必须严格遵循<0（a<b）、==0（a==b）、>0（a>b）约定，否则排序逻辑错乱。我曾见过有人写return strcmp(a,b)>0 ? 1 : -1，导致相等字符串被错误交换——因为strcmp返回值不一定是±1。

3.2 场景二：状态机驱动——用函数指针替代冗长switch

在嵌入式开发中，处理协议解析、设备状态流转时，switch(state){case S1:... case S2:...}容易膨胀。用函数指针数组可让状态转移表一目了然：

// 定义状态枚举 typedef enum { STATE_IDLE, STATE_WAIT_CMD, STATE_PROCESS_DATA, STATE_ERROR } state_t; // 声明状态处理函数类型 typedef state_t (*state_handler_t)(uint8_t *data, size_t len); // 各状态处理函数（返回下一个状态） state_t idle_handler(uint8_t *data, size_t len) { if (len > 0 && data[0] == 0xAA) { printf("收到同步头，进入等待命令\n"); return STATE_WAIT_CMD; } return STATE_IDLE; } state_t wait_cmd_handler(uint8_t *data, size_t len) { if (len >= 2) { uint8_t cmd = data[1]; switch(cmd) { case 0x01: printf("执行读操作\n"); return STATE_PROCESS_DATA; case 0x02: printf("执行写操作\n"); return STATE_PROCESS_DATA; default: printf("未知命令\n"); return STATE_ERROR; } } return STATE_WAIT_CMD; } state_t process_data_handler(uint8_t *data, size_t len) { printf("处理%d字节数据\n", (int)len); return STATE_IDLE; } state_t error_handler(uint8_t *data, size_t len) { printf("进入错误状态，复位\n"); return STATE_IDLE; } // 状态机主循环 int main() { // 状态处理函数指针数组：索引即状态码 state_handler_t state_table[] = { [STATE_IDLE] = idle_handler, [STATE_WAIT_CMD] = wait_cmd_handler, [STATE_PROCESS_DATA] = process_data_handler, [STATE_ERROR] = error_handler }; state_t current_state = STATE_IDLE; uint8_t test_data[] = {0xAA, 0x01, 0x02, 0x03}; for (int i = 0; i < 10; i++) { current_state = state_table[current_state](test_data, sizeof(test_data)); if (current_state == STATE_IDLE) break; } return 0; }

优势对比：

• 可维护性：新增状态只需添加函数+在数组中追加指针，不用改switch分支
• 可测试性：每个状态函数可单独单元测试，无需模拟整个状态流
• 内存友好：数组连续存放，CPU缓存命中率高于分散的switch跳转表

实操心得：在资源受限的MCU上，用static const修饰状态表（static const state_handler_t state_table[]），确保编译器将其放入ROM而非RAM，节省宝贵的SRAM。

3.3 场景三：插件系统骨架——运行时加载行为

大型软件常需支持插件扩展。虽然现代多用动态库（.so/.dll），但函数指针是其核心纽带。我们用POSIXdlopen/dlsym演示最小可行插件：

// plugin_interface.h —— 插件必须实现的接口 #ifndef PLUGIN_INTERFACE_H #define PLUGIN_INTERFACE_H typedef struct { const char *name; int version; // 插件提供的功能函数指针 int (*process)(const char *input, char *output, size_t out_size); void (*cleanup)(); } plugin_t; // 导出函数：插件必须提供此函数返回插件实例 plugin_t* get_plugin(); #endif

// demo_plugin.c —— 示例插件源码 #include <stdio.h> #include <string.h> #include "plugin_interface.h" static int my_process(const char *input, char *output, size_t out_size) { if (!input || !output || out_size == 0) return -1; snprintf(output, out_size, "PLUGIN_V1: %s", input); return 0; } static void my_cleanup() { printf("插件清理完成\n"); } // 全局插件实例（必须命名为get_plugin） plugin_t g_plugin = { .name = "demo_plugin", .version = 1, .process = my_process, .cleanup = my_cleanup }; plugin_t* get_plugin() { return &g_plugin; }

// main.c —— 主程序加载插件 #include <stdio.h> #include <dlfcn.h> #include "plugin_interface.h" int main() { void *handle = dlopen("./libdemo_plugin.so", RTLD_LAZY); if (!handle) { fprintf(stderr, "dlopen失败: %s\n", dlerror()); return 1; } // 获取插件入口函数 plugin_t* (*get_plugin_func)() = dlsym(handle, "get_plugin"); if (!get_plugin_func) { fprintf(stderr, "dlsym失败: %s\n", dlerror()); dlclose(handle); return 1; } // 调用插件 plugin_t *plugin = get_plugin_func(); printf("加载插件: %s v%d\n", plugin->name, plugin->version); char output[256]; if (plugin->process("Hello World", output, sizeof(output)) == 0) { printf("处理结果: %s\n", output); } plugin->cleanup(); dlclose(handle); return 0; }

编译插件：

gcc -shared -fPIC -o libdemo_plugin.so demo_plugin.c

核心原理：dlsym返回void*，我们将其强转为plugin_t* (*)()（指向返回plugin_t*的函数的指针），再调用它获取插件实例。整个过程依赖函数指针的类型安全传递——没有它，插件系统就是空中楼阁。

3.4 场景四：面向对象模拟——C语言的“虚函数表”

C++的虚函数表（vtable）本质就是函数指针数组。我们用C模拟一个简单的“形状”基类：

// shape.h #ifndef SHAPE_H #define SHAPE_H #include <stdio.h> // 基类结构体（包含虚函数表指针） typedef struct shape_s shape_t; // 虚函数表结构体 typedef struct { double (*area)(const shape_t*); void (*draw)(const shape_t*); void (*destroy)(shape_t*); } shape_vtable_t; // 基类结构体（首成员必须是vtable指针，保证继承兼容） struct shape_s { const shape_vtable_t *vtable; }; // 基类公共方法（委托给vtable） static inline double shape_area(const shape_t *s) { return s->vtable->area(s); } static inline void shape_draw(const shape_t *s) { s->vtable->draw(s); } static inline void shape_destroy(shape_t *s) { s->vtable->destroy(s); } // 圆形实现 typedef struct { shape_t base; // 继承基类 double radius; } circle_t; double circle_area(const shape_t *s) { const circle_t *c = (const circle_t*)s; return 3.14159 * c->radius * c->radius; } void circle_draw(const shape_t *s) { const circle_t *c = (const circle_t*)s; printf("画圆，半径=%.2f\n", c->radius); } void circle_destroy(shape_t *s) { // 圆形无额外资源，空实现 } // 圆形虚函数表（全局常量） static const shape_vtable_t circle_vtable = { .area = circle_area, .draw = circle_draw, .destroy = circle_destroy }; // 圆形构造函数 circle_t* circle_create(double r) { circle_t *c = malloc(sizeof(circle_t)); if (!c) return NULL; c->base.vtable = &circle_vtable; c->radius = r; return c; } #endif

// main.c #include "shape.h" #include <stdlib.h> int main() { shape_t *shapes[2]; shapes[0] = (shape_t*)circle_create(5.0); shapes[1] = (shape_t*)circle_create(3.0); for (int i = 0; i < 2; i++) { printf("形状%d面积: %.2f\n", i+1, shape_area(shapes[i])); shape_draw(shapes[i]); shape_destroy(shapes[i]); } return 0; }

这就是C语言实现多态的全部秘密：基类结构体首成员是vtable指针，子类结构体首成员是基类结构体，保证内存布局兼容；所有虚函数调用都通过obj->vtable->func(obj)间接进行。std::vector<std::unique_ptr<Shape>>在底层，也不过是维护着一堆这样的指针数组。

4. 函数指针的避坑指南：那些年踩过的真坑

4.1 常见问题速查表

4.2 我踩过的三个典型深坑

坑一：忘记函数指针也要初始化为NULL

在某次开发电机控制固件时，我定义了一个函数指针数组用于存储不同PID算法：

// 错误示范：未初始化！ static float (*pid_calculate[3])(float err, float dt); // 正确做法：显式初始化为NULL static float (*pid_calculate[3])(float err, float dt) = {NULL};

后果：上电后pid_calculate[0]指向随机内存，调用时直接触发HardFault。调试时发现pid_calculate[0]值是0xdeadbeef——典型的未初始化标记。教训：所有函数指针变量，声明时必须初始化为NULL，调用前必须判空。这是嵌入式开发的铁律。

坑二：在中断服务程序（ISR）中调用非reentrant函数

某项目需在定时器中断里执行用户注册的回调：

// 中断服务程序 void TIM2_IRQHandler(void) { if (user_callback) { user_callback(); // ❌ 危险！ } }

问题：如果user_callback是printf这类使用全局缓冲区的函数，主程序和中断同时调用会破坏缓冲区。更糟的是，某些libc实现的printf不是可重入的。

解决方案：中断里只做标志位设置，主循环中检查标志并调用回调：

volatile static bool callback_pending = false; void TIM2_IRQHandler(void) { callback_pending = true; // 原子操作，安全 } int main() { while(1) { if (callback_pending) { callback_pending = false; if (user_callback) user_callback(); // 在主上下文安全调用 } // 其他任务... } }

坑三：跨模块传递函数指针时的链接问题

在Linux下，将函数指针从主程序传给动态库，动态库再回调主程序函数，常遇到undefined symbol。根源是：默认情况下，动态库看不到主程序的符号。

正确做法（主程序侧）：

// 编译主程序时添加 -rdynamic（等价于--export-dynamic） gcc -rdynamic -o main main.c -ldl

动态库侧保持不变。-rdynamic告诉链接器把主程序所有符号导出到动态符号表，dlsym(RTLD_DEFAULT, ...)才能找到它们。

实操心得：在Makefile中，永远把-rdynamic加在主程序链接命令里，而不是动态库。这是无数人调试半天才发现的隐藏开关。

5. 进阶武器库：函数指针与现代C/C++的协同演进

5.1 C11标准的函数指针增强：_Generic与静态断言

C11引入_Generic关键字，可在编译期根据参数类型选择不同函数，结合函数指针实现类型安全的泛型：

#include <stdio.h> // 定义不同类型处理函数 int process_int(int x) { return x * 2; } double process_double(double x) { return x * 3.14; } char* process_str(char *s) { return s; } // 泛型宏：根据参数类型自动选择函数指针 #define PROCESS(x) _Generic((x), \ int: process_int, \ double: process_double, \ char*: process_str \ )(x) int main() { printf("%d\n", PROCESS(5)); // 调用process_int printf("%.2f\n", PROCESS(2.5)); // 调用process_double printf("%s\n", PROCESS("hello")); // 调用process_str return 0; }

这里_Generic不是运行时函数指针，但它生成的代码本质仍是函数指针调用。配合_Static_assert可做编译期校验：

// 确保回调函数签名符合预期 #define REGISTER_CALLBACK(cb) do { \ _Static_assert(__builtin_types_compatible_p( \ typeof(cb), int(*)(const char*, size_t)), \ "回调函数签名错误：应为 int(*)(const char*, size_t)"); \ callback_fn = (typeof(callback_fn))cb; \ } while(0)

5.2 C++中的平滑过渡：从函数指针到std::function

C++11的std::function是对函数指针的优雅封装，它能容纳函数指针、lambda、bind表达式、成员函数指针：

#include <functional> #include <iostream> int global_func(int x) { return x + 10; } class Calculator { public: int add(int a, int b) { return a + b; } }; int main() { // 1. 存储普通函数指针 std::function<int(int)> f1 = global_func; // 2. 存储lambda（捕获局部变量） int offset = 5; std::function<int(int)> f2 = [offset](int x) { return x + offset; }; // 3. 存储成员函数指针（需绑定对象） Calculator calc; std::function<int(int, int)> f3 = std::bind(&Calculator::add, &calc, std::placeholders::_1, std::placeholders::_2); // 4. 存储std::function本身（支持递归） std::function<int(int)> factorial = [&](int n) -> int { return (n <= 1) ? 1 : n * factorial(n-1); }; std::cout << f1(3) << "\n"; // 13 std::cout << f2(3) << "\n"; // 8 std::cout << f3(2, 3) << "\n"; // 5 std::cout << factorial(4) << "\n"; // 24 }

关键洞察：std::function内部仍用函数指针调度（小对象优化时直接存函数指针，大对象时存虚函数表）。它解决了C函数指针的两大痛点：

• 类型擦除：不再需要为每种签名定义新类型（如typedef int (*cb_t)(int)）
• 闭包支持：能捕获外部变量，而C函数指针只能访问全局/static变量

但代价是：std::function有轻微运行时开销（虚函数调用或函数指针跳转），在极致性能场景（如高频中断处理），原始函数指针仍是首选。

5.3 现代实践建议：何时坚持用原始函数指针？

基于十年工业项目经验，我总结出必须用原始函数指针的三大场景：

1. 裸机/实时操作系统（RTOS）环境
   FreeRTOS的xTaskCreate、Zephyr的k_thread_create等API明确要求函数指针参数。这些系统无STL支持，且对代码体积、执行时间有硬性要求。std::function的虚函数表和异常处理代码会显著增加ROM占用。

2. C语言ABI边界
   当你的模块需被Python（ctypes）、Rust（FFI）、Java（JNI）调用时，函数指针是唯一被广泛支持的回调机制。std::function是C++ ABI私有实现，跨语言无法识别。

3. 超低延迟路径
   在高频交易系统或音频DSP处理中，一次函数调用延迟需控制在纳秒级。std::function的类型擦除层带来1-2个CPU周期开销，而原始函数指针是直接call *%rax，零额外开销。

我的建议：在应用层逻辑中，优先用std::function提升可读性和灵活性；在系统层、驱动层、跨语言接口层，回归原始函数指针——这是对底层的尊重，也是对性能的敬畏。

6. 实战复盘：一个完整函数指针项目的从零搭建

6.1 项目需求：可配置的嵌入式日志系统

某物联网设备需支持多种日志输出方式：

• UART串口（基础调试）
• SD卡文件（长期记录）
• 网络UDP（远程监控）
• 用户自定义（如LED闪烁提示）

要求：运行时可切换输出方式，不重新编译；每种方式有独立初始化/去初始化逻辑。

6.2 架构设计：三层函数指针抽象

┌─────────────────┐ ┌──────────────────┐ ┌─────────────────────┐ │ 日志核心模块 │───▶│ 输出适配器层 │───▶│ 具体输出实现 │ │ log_write() │ │ init(), write(),│ │ uart_init(), │ │ log_set_output()│ │ deinit() │ │ sdcard_write(), │ │ │ └──────────────────┘ │ udp_send(), │ └─────────────────┘ └─────────────────────┘

6.3 核心代码实现

log_core.h

#ifndef LOG_CORE_H #define LOG_CORE_H #include <stdarg.h> #include <stdint.h> // 输出方式枚举 typedef enum { LOG_OUTPUT_UART, LOG_OUTPUT_SDCARD, LOG_OUTPUT_UDP, LOG_OUTPUT_CUSTOM } log_output_t; // 输出适配器结构体（虚函数表） typedef struct { int (*init)(void *config); // 初始化，config由用户传入 int (*write)(const char *buf, size_t len); void (*deinit)(void); } log_output_adapter_t; // 全局日志状态 typedef struct { log_output_adapter_t *adapter; void *adapter_config; uint8_t buffer[256]; // 线程安全环形缓冲区 } log_state_t; // API声明 void log_init(log_output_t output_type, void *config); void log_write(const char *format, ...); void log_set_output(log_output_t output_type, void *config); void log_flush(void); #endif

log_uart.c（UART实现）

#include "log_core.h" #include "uart_driver.h" // 假设已有UART驱动 static void *uart_config = NULL; static int uart_init(void *config) { uart_config = config; // 初始化UART外设 uart_init_hw((uint32_t)config); return 0; } static int uart_write(const char *buf, size_t len) { // 直接写UART寄存器（无阻塞） for (size_t i = 0; i < len; i++) { uart_putc(buf[i]); } return len; } static void uart_deinit(void) { uart_disable(); } // UART适配器实例（全局常量） const log_output_adapter_t uart_adapter = { .init = uart_init, .write = uart_write, .deinit = uart_deinit };

log_core.c（核心逻辑）

#include "log_core.h" #include <string.h> #include <stdio.h> static log_state_t g_log_state = {0}; // 适配器表：索引对应log_output_t枚举值 static const log_output_adapter_t *adapter_table[] = { [LOG_OUTPUT_UART] = &uart_adapter, [LOG_OUTPUT_SDCARD] = &sdcard_adapter, // 其他适配器类似 [LOG_OUTPUT_UDP] = &udp_adapter, [LOG_OUTPUT_CUSTOM] = &custom_adapter }; void log_init(log_output_t output_type, void *config) { if (output_type >= sizeof(adapter_table)/sizeof(adapter_table[0])) { return; } g_log_state.adapter = (log_output_adapter_t*)adapter_table[output_type]; g_log_state.adapter_config = config; if (g_log_state.adapter && g_log_state.adapter->init) { g_log_state.adapter->init(config); } } void log_write(const char *format, ...) { if (!g_log_state.adapter || !g_log_state.adapter->write) { return; } // 格式化到临时缓冲区 va_list args; va_start(args, format); int len = vsnprintf(g_log_state.buffer, sizeof(g_log_state.buffer), format, args); va_end(args); if (len > 0) { g_log_state.adapter->write(g_log_state.buffer, (len < sizeof(g_log_state.buffer)) ? len : sizeof(g_log_state.buffer)-1); } } void log_set_output(log_output_t output_type, void *config) { // 先去初始化当前适配器 if (g_log_state.adapter && g_log_state.adapter->deinit) { g_log_state.adapter->deinit(); } // 切换适配