企业官网建设流程全解析

1. 先把这两个词掰开：一个在说“指针”，一个在说“函数”

函数指针和指针函数，这俩词放一起，几乎是 C/C++ 面试和学习路上被问烂的一对。但我发现一个挺有意思的现象：很多人能背下来“函数指针是指向函数的指针，指针函数是返回指针的函数”，可一旦让他写个声明、或者读一段别人写的代码，立刻就开始犹豫。问题不在于概念难，而在于这两个词的中文语序刚好把重心放在了不同的位置——“函数指针”重心是“指针”，“指针函数”重心是“函数”。中文把它们反着念，读者自然容易串。

这篇文章我想干的事很具体：把这两个东西从声明语法、使用场景、内存模型、编译器视角到实际调试，完整地过一遍。内容会覆盖 C 和 C++ 两种语言的差异，会涉及回调函数、跳转表、成员函数指针、返回堆内存、返回栈地址这些高频坑点，也会顺带聊聊在 VS Code 里怎么配置环境、让智能提示正确解析复杂的函数指针类型。适合已经会写基本 C 语法、但对指针系统还没完全建立直觉的人，也适合工作几年后想回头把这块知识重新梳理一遍的人。

我自己的经验是，这两样东西真正难的地方从来不是“怎么声明”，而是“什么时候该用它”“用了之后谁负责什么”。声明写错了编译器会骂你，逻辑用错了程序会在半夜三点崩给你看。所以下面每一节，我都会尽量把“为什么这么设计”和“这么写会出什么问题”讲透，而不是停在语法层面。

1.1 从一条声明开始，练一套读法

看这行代码：

int (*pf)(int, int);

读它的顺序不是从左到右，而是从变量名pf出发，先看它右边，再看它左边，遇到括号就跳出去继续。这套规则在圈内常叫“右左法则”：

• 从pf开始，右边是)，说明括号内的部分读完，往左看；
• 左边是*，所以pf是一个指针；
• 跳出括号，右边是(int, int)，说明它指向的是接受两个 int 参数的函数；
• 再往左，类型是int，说明这个函数返回 int。

连起来：pf是一个指向“返回 int、接受两个 int 参数”的函数的指针。这就是函数指针。

再看这行：

int* f(int, int);

同样从f出发，右边是(int, int)，f是一个函数，接受两个 int；左边是int*，返回 int 指针。这就是指针函数。

两者的区别其实就藏在那一对括号里。int (*pf)(int, int)因为括号把*和pf绑在了一起，所以pf先成为指针；而int* f(int, int)没有括号，f先和右边的参数列表结合，所以f先成为函数，*只能修饰返回类型。

注意：写函数指针时那对括号绝对不能省。int *pf(int, int)是合法的，但它不是函数指针，而是一个返回 int* 的函数声明，也就是指针函数。少一对括号，语义完全变了，编译器通常也不会报错，只会在你后面赋值时给一个类型不匹配的警告。

1.2 一张表把容易混的写法全列出来

我当年学这块的时候，自己整理过一张对照表，后来发现这张表在整个 C/C++ 学习期里反复能用到，这里直接放出来：

第三行和第六行是很多人工作后还会踩的地方。前者就是常说的跳转表，后者在一堆工厂函数里偶尔能见到。读法仍然是那套右左法则，从最内层的标识符出发，一步步往外剥，剥到哪一层加一层描述。练上十来条声明，这套读法就成肌肉记忆了。

1.3 为什么 C/C++ 要把这两个东西分得这么细

根本原因在 C 的设计哲学：函数不是一等公民，函数名会退化，函数体在内存里也是代码段的一段地址。既然函数在运行时对应一个地址，那就必然需要一种能保存这个地址、并通过它调用函数的类型，这就是函数指针存在的理由。而“返回指针”这件事，是另一条线——函数需要把一块数据的访问权交给调用者，这块数据可能在堆上、静态区、或者别的地方，于是就有了指针函数。

两条线一个解决“调用谁”，一个解决“返回什么”，方向完全不同。C++ 后来在这基础上又长出了std::function、lambda、成员函数指针这些更复杂的东西，但底层机制依然是这两块地基。理解了地基，后面那些高级工具用起来就不会飘。

2. 函数指针：从声明到回调，把这块骨头啃干净

2.1 声明、赋值、调用的三种写法

最基础的用法长这样：

#include <stdio.h> int add(int a, int b) { return a + b; } int sub(int a, int b) { return a - b; } int main(void) { int (*pf)(int, int) = add; /* 也可以写成 = &add */ printf("%d\n", pf(3, 4)); /* 常见调用写法 */ printf("%d\n", (*pf)(3, 4)); /* 解引用后调用，等价 */ printf("%d\n", (**pf)(3, 4)); /* 竟然也等价 */ pf = sub; printf("%d\n", pf(3, 4)); return 0; }

pf = add和pf = &add效果完全一样。原因是标准规定函数名在大多数表达式中会退化为“指向该函数的指针”，所以&是冗余的，加不加都行。同理，调用时pf(3,4)、(*pf)(3,4)、(**pf)(3,4)也都等价，因为对函数指针解引用得到的是函数指示符，函数指示符又会退化回函数指针。

实操心得：虽然三种写法都合法，但团队代码里最好统一。我自己习惯写pf(3, 4)，简洁；如果是要强调“这里是通过指针调用”，用(*pf)(3,4)更显眼。两种混着写会让 review 的人分心。至于(**pf)，知道它合法就行，别真用。

赋值时有一个坑：函数指针的类型包含完整的函数签名，返回值类型和参数列表必须逐一匹配。int (*pf)(int, int)不能被赋值为double calc(int, int)，也不能被赋值为int calc(double, double)。C 编译器通常只给个 warning，然后照常生成代码——这意味着你可能拿到一份错误类型转换后的调用，返回值被按另一种方式解释。这种 bug 极难查，所以把-Wall -Wextra打开。

另外有两个常被忽略的事实：函数指针不支持指针算术，pf + 1在标准里没有定义；函数指针可以比较相等，但必须是同类型之间比。把函数指针强转成void*在 C 里是实现定义行为，在 C++ 里干脆不允许隐式转换，这类转换能避开就避开。

2.2 用 typedef / using 把类型名收干净

每次写int (*)(int, int)很累，起个别名会舒服很多：

typedef int (*BinOp)(int, int); BinOp get_op(char c) { switch (c) { case '+': return add; case '-': return sub; default: return NULL; } }

C++11 之后有了using，语义更直观：

using BinOp = int (*)(int, int);

这里有个很多人第一次见会愣住的点：typedef int (*BinOp)(int, int);里的BinOp是别名本身，不是BinOp*，你看它在声明中的位置就能明白，它替换的正是(*BinOp)整体。所以写函数返回函数指针类型时，直接写BinOp get_op(char)，不需要再加星号。

如果要声明“返回函数指针的函数”，用 typedef 后会很干净：

typedef int (*BinOp)(int, int); BinOp pick(char c); /* 返回函数指针的函数 */

而不加 typedef 的原始写法是：

int (*pick(char c))(int, int);

这行我第一次看到的时候盯了半分钟。用别名换来的可读性提升是巨大的，特别是在头文件里暴露接口时。

注意：C 和 C++ 里typedef的位置规则不同。typedef int (*F)(int);在 C 里完全合法；C++ 也兼容，但如果你还想写using F = int(*)(int);，只有 C++11 及以上支持。跨语言混编的项目里，头文件中两种写法的可见性要提前确认。

2.3 当参数传递：回调函数才是它的主战场

函数指针最经典的用途就是当回调传参。标准库的qsort就是教科书级例子：

void qsort(void *base, size_t nmemb, size_t size, int (*compar)(const void *, const void *));

第四个参数就是函数指针。我们可以按分数降序排一组学生：

#include <stdio.h> #include <stdlib.h> typedef struct { char name[32]; int score; } Student; int by_score_desc(const void *a, const void *b) { const Student *pa = (const Student *)a; const Student *pb = (const Student *)b; if (pb->score > pa->score) return 1; if (pb->score < pa->score) return -1; return 0; } int main(void) { Student s[] = { {"Li", 88}, {"Wang", 95}, {"Zhao", 76} }; size_t n = sizeof(s) / sizeof(s[0]); qsort(s, n, sizeof(Student), by_score_desc); for (size_t i = 0; i < n; ++i) printf("%-8s %d\n", s[i].name, s[i].score); return 0; }

比较函数里返回pb->score - pa->score是很多人爱写的短写法，但它有个隐患：如果两个 int 相差特别大，相减会溢出，比较结果就乱了。上面用三个 if 判断虽然啰嗦，但永远正确。这个细节在数据规模小的时候看不出来，但一旦线上真的出现极端值，排查成本远比多写两行代码高。

回调还常见于事件系统、状态机、插件注册等场景。手写一个简单的注册表：

typedef void (*EventHandler)(int event_id, void *userdata); #define MAX_HANDLERS 16 static EventHandler handlers[MAX_HANDLERS]; static int handler_count = 0; int register_handler(EventHandler h) { if (h == NULL) return -1; if (handler_count >= MAX_HANDLERS) return -1; handlers[handler_count++] = h; return 0; } void fire_event(int id, void *data) { for (int i = 0; i < handler_count; ++i) { if (handlers[i]) handlers[i](id, data); } }

这里有两个防御点值得强调：注册时判空，触发时再判一次。因为使用方可能在运行期修改了数组内容，双重判断成本可以忽略，但能挡住一次崩溃。

常见坑：回调函数指针是“活”的，它指向的代码地址不会变，但它所属对象的生命周期需要你自己管。在 C++ 里把一个已经析构对象的成员函数注册成回调，程序不会立刻炸，而是在某次事件触发时才炸，堆栈看起来离问题源头十万八千里。注册回调时最好同时约定一个unregister接口，对象析构前先注销。

2.4 函数指针数组：写状态机和命令分发的最爱

把若干个函数指针放进数组，用索引去取，就得到一个跳转表。写小型状态机、解释器、命令分发器时非常好用：

typedef int (*BinOp)(int, int); static int op_add(int a, int b) { return a + b; } static int op_sub(int a, int b) { return a - b; } static int op_mul(int a, int b) { return a * b; } static int op_div(int a, int b) { return b ? a / b : 0; } enum { OP_ADD, OP_SUB, OP_MUL, OP_DIV, OP_COUNT }; static BinOp table[OP_COUNT] = { op_add, op_sub, op_mul, op_div }; int dispatch(int op, int a, int b) { if (op < 0 || op >= OP_COUNT) return 0; return table[op](a, b); }

比switch版本来得紧凑，扩展新操作只需要加一个枚举和一条表项。但跳转表也不是无脑上，它的前提是操作 ID 能直接当索引用，而且范围受控。如果外部输入直接当索引，越界访问会读到垃圾函数指针然后跳飞，所以dispatch里那句边界判断是必须的。

另一个变体的思路是“表驱动 + 描述字段”，每个操作附带名字和参数个数：

typedef struct { const char *name; int argc; BinOp fn; } Command; static const Command cmds[] = { { "add", 2, op_add }, { "sub", 2, op_sub }, { "mul", 2, op_mul }, };

查表时按名字线性扫描，虽然慢，但命令行工具这类场景完全够用，可读性还高。真正性能敏感的热路径才需要考虑排序加二分，或者做哈希。

实操心得：跳转表里的函数尽量保持签名一致，这让表、枚举、分发逻辑三者可以批量维护。一旦某个函数签名不一样，你就要么做一层包装，要么引入类型转换，代码立刻开始变味。

2.5 C++ 的成员函数指针：一个容易翻车的加强版

到了 C++，函数指针多了一种形态——指向成员函数的指针：

struct Widget { int value = 0; int get() const { return value; } void set(int v) { value = v; } }; int main() { int (Widget::*pmf)() const = &Widget::get; Widget w; w.value = 42; std::cout << (w.*pmf)() << "\n"; // 通过对象调用 Widget *pw = &w; std::cout << (pw->*pmf)() << "\n"; // 通过指针调用 }

pmf是成员函数指针，调用时必须配合对象或者对象指针，用.*或->*运算符。这点和普通函数指针完全一样不了，千万别写成pmf()。

成员函数指针有几个硬性约束值得记牢：它的大小在多数实现上是 8 字节，但涉及多继承或虚继承时可能膨胀到 16 字节；它不能和普通函数指针互相转换；它不能塞进void*；静态成员函数例外，静态成员函数没有 this 指针，取地址得到的其实就是普通函数指针，可以正常放进函数指针数组。

调用非虚的成员函数指针，编译器可以静态解析；但如果是虚函数，就会走虚表，开销和普通虚调用差不多。所以在需要极致性能的地方，把成员函数指针换成一个接受Widget*的普通函数指针，有时能省掉一层间接寻址。

再看一个更现代的写法。C++11 之后，无捕获的 lambda 可以隐式转换为函数指针：

int (*fp)(int, int) = [](int a, int b) { return a * b; };

而有捕获的 lambda 不能这样转，只能用std::function或者模板参数接：

#include <functional> std::function<int(int, int)> f = [factor = 10](int a, int b) { return (a + b) * factor; };

std::function用起来舒服，但要注意它背后有类型擦除，可能涉及堆分配，调用开销比裸函数指针大。热路径上，我一般会先用模板 + lambda 让编译器内联，性能不够再考虑回到函数指针，而不是一上来就std::function。

注意：C++ 里如果要给重载函数取地址并转成函数指针，直接写&overloaded会因为无法确定重载版本而编译失败。正确做法是用static_cast指定完整签名：

int (*fp)(int, int) = static_cast<int(*)(int, int)>(&overloaded);

这个坑在给标准库算法传重载函数时特别常见。

3. 指针函数：返回值里藏着的那些雷

3.1 返回堆内存：谁申请谁释放，必须说清楚

指针函数最正统的用法就是返回一块动态申请的内存：

#include <stdio.h> #include <stdlib.h> #include <string.h> char *make_greeting(const char *name) { size_t n = strlen(name) + 8; char *buf = (char *)malloc(n); if (buf == NULL) return NULL; snprintf(buf, n, "Hello %s", name); return buf; } int main(void) { char *msg = make_greeting("World"); if (msg) { puts(msg); free(msg); } return 0; }

这里的规则很硬：谁申请，谁负责，或者由接口约定清楚由谁释放。上面这种malloc出去的指针，调用者有责任free。如果接口是给别的团队用的，头文件注释里最好明确写一句“返回的内存需要由调用方释放”，这种约定不清导致的泄漏在跨模块场景里非常多。

C++ 里更推荐用智能指针表达所有权：

#include <memory> #include <cstring> std::unique_ptr<char[]> make_greeting(const char *name) { size_t n = std::strlen(name) + 8; auto buf = std::make_unique<char[]>(n); std::snprintf(buf.get(), n, "Hello %s", name); return buf; }

返回值语义上就自带“我是唯一所有者”的信息，调用者不需要看注释就知道该怎么处理。C++14 之后make_unique可用，C++11 需要自己包一层或者直接用new。

实操心得：一个指针函数如果返回的是新分配的资源，在 C++ 里几乎永远不该返回裸指针。裸指针返回的接口，在异常路径上特别容易漏释放。我自己维护过的几个老模块，内存泄漏基本都出在“返回裸指针 + 中途 return”这种结构上。

3.2 返回静态缓冲区的两个致命问题

另一个常见的指针函数写法是返回静态缓冲区：

#include <ctype.h> #include <stdio.h> char *to_upper_static(const char *s) { static char buf[256]; size_t i = 0; for (; s[i] != '\0' && i < sizeof(buf) - 1; ++i) buf[i] = (char)toupper((unsigned char)s[i]); buf[i] = '\0'; return buf; }

看起来很省事，不用管释放。但它埋了两个雷。

第一个雷：多次调用会互相覆盖。因为返回的是同一个静态数组，第二次调用会把第一次的结果冲掉。下面这行代码是典型翻车现场：

printf("%s %s\n", to_upper_static("abc"), to_upper_static("def"));

你期望看到ABC DEF，实际很可能输出DEF DEF。更糟的是，函数参数的求值顺序在标准里没有规定，编译器先算哪个都合法，所以不同编译器、不同优化等级下结果还可能变。这类 bug 换台机器就复现不了了。

第二个雷：线程不安全。静态缓冲区在所有线程之间共享，多线程同时调用必然互相踩。

如果确实需要返回字符串，又不方便交出所有权，可以考虑改成调用者传缓冲区：

int to_upper_into(const char *src, char *dst, size_t cap) { if (!src || !dst || cap == 0) return -1; size_t i = 0; for (; src[i] != '\0' && i + 1 < cap; ++i) dst[i] = (char)toupper((unsigned char)src[i]); dst[i] = '\0'; return (int)i; }

这样责任清晰、线程安全、不会互相覆盖。只是调用方要多准备一块内存。这种“输入输出分离”的接口风格在老代码重构时特别有用，改动量小，收益却很大。

3.3 返回栈上地址：编译器都看不下去了

这个错误太经典，以至于现代编译器已经能直接给你告警：

int *bad(void) { int x = 10; return &x; /* 严重错误：返回局部变量地址 */ }

x在函数返回后生命周期就结束了，那块栈空间随时可能被下一个函数调用覆盖。返回值不是空指针，看起来能编译，运行时读到的却是不确定的值，甚至可能触发段错误。GCC 和 Clang 会给出-Wreturn-local-addr之类的告警，这个选项在-Wall里就开着，所以务必把告警打开并且当错误看。

还有一种变体更隐蔽：返回局部数组里某个元素的地址、返回局部结构体的成员地址，本质都一样。只要这个地址指向栈帧内部，就是错的。

检查清单：看到一个函数返回指针，先问三句话——这块内存是堆上的吗？是静态/全局的吗？是调用者传进来的吗？如果都不是，那就是栈上的，基本可以判定有问题。

3.4 C++ 里返回指针的函数还有哪些更稳的写法

到了 C++，返回数据的接口有一整条替代路径。返回std::vector、std::string这类值语义容器是最省心的，现代编译器有 RVO 和移动语义，拷贝开销通常不用担心：

#include <vector> std::vector<int> make_squares(int n) { std::vector<int> v; v.reserve(n); for (int i = 0; i < n; ++i) v.push_back(i * i); return v; }

如果确实需要返回一块裸数组，用std::unique_ptr<T[]>；如果是共享场景，用std::shared_ptr<T>。只有在和 C 接口对接、或者性能极端敏感的场景下，才考虑退回裸指针，并且加注释说明所有权。这个决策顺序我用了很多年，基本上能覆盖九成以上的需求。

4. 环境配置与调试实操：在 VS Code 里把这两样东西看清楚

这一段聊点动手的东西。函数指针和指针函数的类型经常嵌套得很深，光靠肉眼看代码容易绕晕，借助 IDE 的智能提示和调试器会轻松很多。下面以 VS Code 上的 C/C++ 开发环境为例，把关键配置文件讲一遍。

4.1 三个配置文件各自负责什么

VS Code 本身只是个编辑器，C/C++ 的智能提示、编译、调试分别由三个文件驱动，职责划分很清晰：

一份适合练习函数指针的c_cpp_properties.json：

{ "version": 4, "configurations": [ { "name": "Linux", "includePath": [ "${workspaceFolder}/**", "${workspaceFolder}/include" ], "defines": ["DEBUG=1"], "compilerPath": "/usr/bin/gcc", "cStandard": "c17", "cppStandard": "c++17", "intelliSenseMode": "linux-gcc-x64" } ] }

对应的tasks.json，编译时打开全部常用告警：

{ "version": "2.0.0", "tasks": [ { "label": "build-c", "type": "shell", "command": "/usr/bin/gcc", "args": [ "-g", "-O0", "-Wall", "-Wextra", "-Wpedantic", "-Wreturn-local-addr", "-std=c17", "${file}", "-o", "${fileDirname}/a.out" ], "group": { "kind": "build", "isDefault": true }, "problemMatcher": ["$gcc"] } ] }

launch.json里最关键的是preLaunchTask必须和tasks.json的label对上，否则按 F5 调试时用的是旧的可执行文件，你改了代码却发现断点位置不对，会怀疑人生：

{ "version": "0.2.0", "configurations": [ { "name": "Debug C", "type": "cppdbg", "request": "launch", "program": "${fileDirname}/a.out", "args": [], "cwd": "${fileDirname}", "MIMode": "gdb", "miDebuggerPath": "/usr/bin/gdb", "preLaunchTask": "build-c", "setupCommands": [ { "description": "Enable pretty-printing", "text": "-enable-pretty-printing", "ignoreFailures": true } ] } ] }

提示：program路径里的可执行文件名一定要和tasks.json里-o的输出保持一致。这看起来是废话，但我见过至少三次因为改名漏改一处导致调试器一直加载旧程序的案例。

4.2 智能提示的路径优先级和结构体成员补全异常

很多人以为includePath里写的路径就是全部，其实 IntelliSense 解析一个头文件时，搜索顺序大致是这样的：

1. 当前打开文件所在目录；
2. c_cpp_properties.json里的includePath，按数组顺序从头到尾；
3. compilerPath指定的编译器自带的系统头文件路径和内置宏；
4. 如果配置了compileCommands，它会提供最精确的编译参数，优先级最高。

知道这个顺序之后，很多“同名头文件被解析错版本”的问题就好查了。比如项目里有两个config.h，一个在src/，一个在third_party/，includePath里src/写在前面，那么 IntelliSense 就会一直用第一份，哪怕编译期实际用的是另一份，两边行为就会不一致。

关于结构体成员补全不出来这个问题，我自己总结了几条排查路径：

• 检查defines是否漏了条件编译宏。头文件里用#ifdef包住的成员定义，如果宏没告诉扩展，它就直接不解析，成员自然补全不出来。
• 检查includePath里是否存在同名文件导致解析到了另一份。
• 用命令面板里的C/C++: Rescan IntelliSense或者重启智能提示引擎，缓存失效会导致补全内容滞后。
• 路径里带空格或非 ASCII 字符时，扩展解析有时会出错，换成纯英文无空格路径最稳。
• 项目体量大时尽量避免在includePath里用${workspaceFolder}/**这种递归通配，索引全仓库会明显变慢，改成列具体目录更实用。

如果这些还解决不了，可以考虑启用compile_commands.json。CMake 项目加上-DCMAKE_EXPORT_COMPILE_COMMANDS=ON就能生成，然后在配置里指向它，智能提示就能拿到和真实编译一模一样的参数，包括头文件搜索顺序和宏定义，很多玄学问题会直接消失。

4.3 用调试器把函数指针的指向看清楚

函数指针在调试器里是可以直接观察的。用 gdb 举几个常用操作：

gdb ./a.out (gdb) break main (gdb) run (gdb) print pf (gdb) print *pf (gdb) info line *pf

print pf会打印它保存的地址，通常还会带上函数名；print *pf会显示它指向的函数信息；info line *pf会告诉你这个地址对应源码的哪一行。调试跳转表的时候，这几个命令组合用非常有效，你可以直接看到table[2]到底指向哪个函数，不用翻代码猜。

在 VS Code 的调试面板里，可以在 watch 表达式里写类型转换：

*(int(*)(int,int))pf

或者直接 watch 数组元素：

table[0] table[1]

如果程序是段错误，先在launch.json里保证-g -O0，然后用 gdb 的bt看堆栈，一般能立刻定位到是哪一次函数指针调用出了问题。

另外强烈建议在调试阶段加上 sanitizer：

gcc -g -O0 -fsanitize=address,undefined -fno-omit-frame-pointer main.c -o a.out

AddressSanitizer 能抓到堆越界、使用已释放内存；UndefinedBehaviorSanitizer 能抓到很多标准未定义行为，包括空函数指针调用、返回栈地址后的读取等。这些工具在练习函数指针时非常值钱，因为很多错误在普通运行下“看起来是对的”，sanitizer 会当场拦住。

4.4 退出代码也是线索

程序崩了之后，终端常常会打印一个退出代码，别忽略它。常见几个：

看到 139 基本可以往指针问题上想，看到 134 则更可能是主动中止或者内存管理出错。知道这个映射，能让你在日志里一眼缩小排查范围。

5. 常见问题速查与踩坑记录

5.1 编译期告警：先把签名对齐

编译期的错误和告警大部分都和签名不匹配有关，整理一张速查表：

我个人的习惯是编译阶段直接开-Werror，把告警当错误处理。这样在 CI 上就不会因为一条被忽略的告警，最后演变成线上崩。代价是改老代码时会先修一堆告警，但这个一次性成本非常值得付。

5.2 运行期排查：崩溃和结果异常

运行期的问题比编译期难查得多，因为它们不容易复现。把常见现象归一下类：

有一个技巧很值得试：在注册回调时把函数指针打印出来，在注销时也打印一遍，成对出现才是正常的。多线程环境下日志会出现交错，加个序号更清楚。这个办法帮我在一个跨线程回调的模块里定位过两次悬垂指针问题。

5.3 一些我用血泪换来的经验

第一条，空函数指针必须判。不管接口设计得多严谨，只要这个指针来自外部，调用前就判一次。代价是一次比较，收益是挡住一类必崩的 bug。

第二条，函数指针参数类型里出现void*时，一定要在注释里写清楚它实际会转成什么类型。void*意味着类型信息丢失，配合函数指针使用时，调用方和使用方两边一旦理解不一致，程序会以很隐蔽的方式崩。

第三条，函数指针数组的长度不要靠人工同步。加了枚举忘了加表项，或者顺序调换了，这类错误编译器不会报。可以加一条编译期断言：

_Static_assert(sizeof(table) / sizeof(table[0]) == OP_COUNT, "table size mismatch with OP_COUNT");

C++ 里对应的是static_assert。这一行能挡住很多人为疏忽。

第四条，如果你在写库，指针函数的返回值语义一定要在头文件里写死。是调用者释放，还是库内部管理，还是指向静态数据不能改。这三种约定的使用方式完全不同，写错注释还不如不写。

第五条，C++ 里能不用裸函数指针就不用。需要回调时优先考虑 lambda 加模板，需要存储时优先考虑std::function，只有在性能瓶颈明确、或者要和 C 接口对接时才退回裸指针。这不是教条，而是我在多个项目里反复验证过的：裸函数指针带来的灵活性，往往被它带来的生命周期管理成本抵消掉。

最后再分享一个自己常用的小工具。写函数指针相关代码时，我会在文件顶部加一个静态断言检查预期大小：

_Static_assert(sizeof(void (*)(void)) == sizeof(void *), "unexpected function pointer size on this platform");

它不会帮你抓业务 bug，但能在换平台或者换编译器时，第一时间告诉你指针模型变了，省得你在一堆诡异行为里瞎猜。这种小检查写起来几秒钟，用起来能省几个小时。