屏幕转过来，上面就一行init_board();，编译零警告，烧进去板子就是没动静，gdb 里那个断点永远是灰的。这类"C语言 void 函数不执行"的报障我这些年接过的次数两只手数不过来，而且每次的真凶都不太一样——有的是那一行干脆被编译器当成了别的语法结构，有的是调用了却被优化器抹平，还有的其实执行得好好的，只是 printf 的字符躺在缓冲区里没吐出来。"void 函数调用问题"之所以让人挠头，恰恰因为"不执行"是个主观描述，它把三种截然不同的故障现象压缩进了同一个句子里，你越盯着源码看，越容易被自己的眼睛骗。

下面我按"先分类、再定位、最后给修法"的顺序，把 void 函数调用失效的常见成因一个个拆开。适合已经能写 C、但被这种"玄学问题"卡住半天的人，也适合带新人的同学拿去当排查手册。读完你至少能在三分钟内判断出：眼前这个"没执行"，到底是没被调用、没进得去，还是进去过但你没看见。

1. 先把"不执行"拆成三件事：没调用、没进去、没看见

动手改代码之前先分类，这一步省不掉。同样是"void 函数没跑"，这三类的验证手段、修复成本、甚至责任归属都不一样。我见过太多人一上来就加 printf、加 volatile、加__attribute__((noinline))，把所有招数都招呼一遍，最后发现是头文件里的宏把函数名替换掉了——折腾两小时，实际改动只有一行。

分类的意义在于：每一类都对应一条最短的验证路径。你只要走对路，大多数问题在两分钟内就能定性，剩下的时间才是修。

1.1 第一类：调用语句在被编译之前就已经不存在了

这一类问题的共同特征是"源码里看着有，实际编译进去的东西里没有"。能造成这种结果的东西不少：宏展开把init()换成了空语句、#ifdef分支没生效、清理代码时误删了、或者最经典的——那一行根本不是调用语句而是函数声明。

判定方法特别简单：让它停在第 4 行之前。gcc -E main.c -o main.i之后直接翻预处理结果，搜索函数名。搜不到，说明被宏或条件编译干掉了；搜到了但形态不对（比如变成了void init();带类型名），那是语法层面的问题，跟第 2 章要说的坑是同一个。我习惯用gcc -E -P去掉行号标记，输出更清爽，搜索起来也快。

有些项目用 CMake 生成一堆-D宏，构建配置写错一个开关，整个模块的初始化调用就集体消失了。这种情况在本地编译器和 CI 环境不一致时尤其隐蔽：你本地跑得好好的，CI 上跑出来就是不对，因为两边的CMAKE_BUILD_TYPE不一样，走的是不同的#if分支。

1.2 第二类：call 指令生成了，但执行流没落到目标函数上

这一类要用反汇编来判。objdump -d main.o里能看见call，说明调用是真实存在的，问题出在"跳到哪儿去了"。常见成因包括链接到了同名的另一个实现、隐式声明让参数传递错位、函数指针指向了空壳、栈被越界写坏导致返回地址错乱，以及跨语言调用时符号名对不上。

这类的麻烦之处在于程序往往不崩，只是行为不对。调用确实发生了，控制权也确实转移了，只是落到了你不期望的那段代码上。表现出来就是"函数好像没执行"，因为你在目标函数里设的断点确实没被撞上——断点设在 A 函数，执行流去的是 B 函数。

验证的时候我会先看符号表再看好反汇编。nm main.o | grep 函数名看这个符号是在本文件定义的（T/t）还是引用的（U），W是弱符号，弱符号意味着链接期可能被别人覆盖。符号层面清清楚楚，这一类的排查就不会迷路。

1.3 第三类：函数跑完了，只是你没有任何可观察的证据

这一类最容易让人怀疑人生，因为它包含了大量"其实没问题"的误报。stdout 是全缓冲模式、断点被优化器挪了位置或干脆没设上、日志级别过滤掉了这条输出、多线程下另一个线程还没轮到、中断上下文里调试器停不住——这些情况下函数执行得好好的，只是你的观测手段失效了。

我印象最深的一次是有人拿着串口助手的空窗口来找我，说初始化函数没执行。最后发现printf末尾没加\n，标准输出接的是重定向到文件的管道，全缓冲模式下 4KB 才刷一次，程序跑完缓冲区随着进程退出一起丢了。函数执行了一百遍，一个字符都没留下。

判断这类问题有个粗暴但好用的办法：在函数入口写一个全局的volatile计数器，程序跑完在别的地方打印它。如果计数器涨了，函数百分百执行过，问题在你的观测链路上；如果没涨，回到前面两类去查。

2.void foo();写在函数体里，那一条是声明，不是调用

这是"C语言 void 函数调用问题"里出现频率最高的一个坑，也是最好笑的一个——你写下这行代码的时候满心以为在调用，编译器则一脸平静地把它当成了函数声明，然后什么都没做，还不给你任何提示。我刚入行那会儿在这上面栽过，后来带新人也见过好几次。

2.1 一个类型名开头的语句，C 语言一律先按声明解释

C 的语法在语句层面有一个硬性约定：以类型说明符（void、int、char、struct标签等）开头的，优先解析为声明。所以

void do_init();

在函数体内部，编译器读到的信息是"这里声明了一个返回 void、参数列表未指定的函数do_init"，不是"调用do_init"。整个main里一个call都不会生成。

这不是编译器偷懒，是语法本身就这么定的。声明和表达式语句共用同一套 token 序列，C 选择了最简单的消歧规则——看见类型名就当声明。C++ 里有个更出名的版本叫"最令人烦恼的解析"（most vexing parse），Type obj();被解析成函数声明而不是对象定义，本质上是同一个设计选择的副作用。

有意思的是，这个声明还可能产生额外影响。如果do_init在别处有原型，这行重复声明在-Wredundant-decls下会报；如果原型不一致，编译器可能给出类型冲突的错。但只要你没开这些警告，它就是彻底静默的。

2.2 复现：改一个词，行为天差地别

#include <stdio.h> void do_init(void) { printf("init running\n"); } int main(void) { printf("start\n"); void do_init(); /* 声明，不是调用 */ printf("end\n"); return 0; }

gcc -Wall -Wextra编译，一条警告都没有，运行输出只有两行：

start end

把void去掉：

do_init(); /* 这才是调用 */

输出变成三行，init running夹在中间。整个修复过程就删了五个字符。

验证的话我推荐直接看汇编，比看源码可靠得多。gcc -S -O0 main.c生成.s文件，搜call关键字，一秒钟就能数出这个文件里到底调用了几次。有call do_init说明调用了，没有就是没调用，不用猜。这招比单步调试快得多，尤其是在你怀疑编译产物和你看到的源码不一致的时候。

2.3 编译器为什么不给你一个警告

很多人第一反应是"这么坑的写法编译器居然不提醒？"。原因在于块作用域的局部声明在 C 里是完全合法的语法，有正当用途——比如你想在某个函数内部临时收窄一个全局函数的可见性，或者故意隐藏原型冲突。编译器没法判断你写这行是"想调用但忘了删类型名"还是"真的想声明"，所以它选择沉默。

想让编译器多嘴，可以开-Wstrict-prototypes。这个警告针对的是"()形式的声明不算原型"这个问题，会提示function declaration isn't a prototype，间接让你注意到这里有声明语句。-Wredundant-decls在重复声明时也会报。不过说实话，这两个开关的噪音都不小，老项目里打开会刷屏。

更实用的做法是编码规范层面禁掉：函数体内禁止出现函数声明。这一条写进团队的 lint 规则里，比指望编译器提醒靠谱。很多静态检查工具都有对应的misra或自定义规则，接进 CI 之后这类问题基本绝迹。

2.4 顺带说清void f()和void f(void)的差别

这条支线经常和上面的坑一起出现，值得单独说。在 C23 之前，void f()表示"参数列表未指定"，意思是这个函数可以接受任意数量和类型的参数，编译器不做检查；void f(void)才明确表示"不接受参数"。这两个写法在旧标准下是不同的类型。

后果是：如果定义处写void f(void)、调用点看到的是void f()，编译器不会报错，但也不会帮你检查参数。传错参数数量时，多余的参数会被压栈，被调函数按自己的约定清理栈，轻则行为诡异，重则栈失衡直接崩。这类问题在跨编译单元的调用里特别难查，因为单个文件编译时一切正常，问题只在链接后的二进制里发作。

C23 把void f()规范成了和void f(void)等价，这个历史包袱总算卸载了。但你手上的代码库未必用到 C23，交叉编译工具链更是常年停留在 C99/C11。所以在头文件里老老实实写全(void)，是我一直坚持的习惯，多敲四个字符，省掉一整类问题。

3. 优化器凭什么敢把你的调用直接删掉

这条坑的迷惑性比上一条强得多，因为它跟优化等级强相关：-O0下跑得好好的，切到-O2就失效了。很多人在 Release 构建里第一次遇到，还以为是自己某次改动引入的 bug，git bisect 找了一下午。

3.1 as-if 规则给了优化器极大的自由度

C 标准里有一条核心约定：只要程序的可观察行为不变，编译器可以做任何变换。所谓可观察行为，指的是 volatile 对象的访问顺序、写入文件的数据、交互式设备的输入输出。除此之外的一切——中间变量、寄存器分配、函数调用是否存在——都在编译器的自由裁量范围内。

所以当编译器看到一个函数：函数体为空、或者只有局部计算且结果没被使用、或者只写了一个之后再也没人读的静态变量，它会毫不犹豫地把整个调用抹掉。在它眼里这不是"删你的代码"，这是"消除无效工作"。

GCC 的-fdump-tree-optimized能把这套判断过程摊开给你看。加上-fdump-tree-all会生成一堆中间文件，里面的optimized版本基本就是最终形态的伪代码，函数没了就是真没了。

3.2 一个必须开-O2才能复现的例子

#include <stdio.h> static void dummy(void) { } int main(void) { dummy(); printf("alive\n"); return 0; }

gcc -O0跑出来能看到dummy被调用（虽然什么都没干）。gcc -O2之后，dummy这个符号在整个产物里都消失了，main里连一条call dummy的影子都没有。

更具迷惑性的是"有计算但无副作用"的版本：

static void compute(void) { int a = 1 + 2; int b = a * 3; (void)b; }

(void)b;这个转换很多老代码里都有，本意是"我知道这个变量没用，别警告我"。但在优化器眼里，它恰恰是一份完美的删除许可——这个函数确实什么都没干。

要判断你的函数是不是被这样处理了，最快的办法是看符号表。nm a.out | grep 函数名，如果 Release 版本里这个符号压根不存在，而源码里明明是普通函数定义（非 static），那说明它被内联或者被判定为无副作用后消除了。加-fno-inline重编译一下对比，如果符号回来了，那就是内联干的。

3.3 让调用"钉死"的三种手段，以及各自的代价

第一种是制造真实的副作用。写一个全局变量，而且这个变量在别处会被读取：

volatile unsigned int g_stage; void enter_init(void) { g_stage = 1; }

volatile修饰保证这次写入不会被优化掉，因为对 volatile 对象的访问属于可观察行为，标准明确要求编译器保留。这也是嵌入式里写硬件寄存器的标准做法。

第二种是给函数加属性，明确告诉编译器"别动它"：

static void __attribute__((noinline, used)) keep_alive(void) { /* 空函数也保留 */ }

noinline禁止内联，used表示"即使看起来没人用也要保留这个函数"。注意used和unused是两个相反的属性，别写反了。这两个属性是 GCC/Clang 的扩展，MSVC 对应的是__declspec(noinline)，跨编译器项目要用宏包一层。

第三种是编译屏障：

__asm__ __volatile__("" ::: "memory");

这一行不产生任何指令，但它告诉优化器"这之后的内存状态我不做任何假设"，相当于在代码流里插了一道看不见的栅栏。在内核代码和驱动里用得非常普遍，用户态也并非用不上——只要你需要强制编译器在某个点上做出保守判断。

3.4 volatile 的两个常见误用

第一个误用是拿它当同步手段。volatile只保证"这个变量每次访问都真的去内存里读/写，不缓存到寄存器"，它不保证原子性，也不构成内存屏障，多线程下该加锁还是得加锁。见过太多人用volatile int flag做线程间通知，在 x86 上碰巧能跑，换到别的架构上就是随机挂。

第二个误用是认为标了volatile的变量所涉及的整个函数都不会被优化。不成立。void f(void) { volatile int x = 1; }这个函数本身仍然可能被内联或者被调用点消掉——因为函数调用本身不一定产生可观察行为，每个局部 volatile 变量的写入虽然保留，但如果没有可观察的全局影响，整个函数体还是可以被裁剪。要让函数级别"存活"，得靠noinline和used，不是 volatile。

4. 编译链接都过了，符号却指到了别处

这一类问题最阴，因为构建过程中你看到的是满屏绿色，一个 warning 都没有，可程序跑起来就是不对。它需要你对链接器的行为有一点直觉，光看源码永远看不出问题。

4.1 隐式声明：C99 的警告，C23 的错误

老代码里最常见的写法是不带头文件直接调函数：

int main(void) { init_system(); /* 没有包含声明它的头文件 */ return 0; }

C89 时代这完全合法，编译器推断出extern int init_system()。C99 起取消了这个特性，但 GCC 在很多年里只给个implicit declaration of function的警告，-std=c89甚至还能编译通过。到 C23，这就直接是编译错误了。

哪怕只是警告级别，问题也照样存在：如果init_system实际返回void，调用方按int处理，会去读一个并不存在的返回值寄存器；如果参数列表对不上，压栈的数量和顺序全乱。这类错位在简单函数上往往"碰巧能跑"，一旦函数带了多个参数或者用了浮点参数，程序就会以一种完全没有规律的方式挂掉。

同理，返回值类型不匹配的问题也一样隐蔽。函数定义是void，调用点以为是int，编译器生成的调用约定就不同，尤其是带返回结构的函数。看符号表能发现端倪——nm里符号类型对得上，但调用方生成的代码对不上，得看反汇编才能确认。

4.2 同名符号与静态函数的作用域陷阱

链接器处理两个同名全局符号时会报multiple definition，看着很粗暴，至少你知道出问题了。麻烦的是这几类"不报错"的组合：

• 一个是static（局部符号）、一个是全局符号。静态版本只在编译单元内可见，所以不冲突，但如果你本意是调用全局版而实际调用到了本文件里的静态版，行为就悄悄变了。
• 一个是普通全局符号、一个是弱符号（__attribute__((weak))）。链接器安静地选一个，不吭声。
• 静态库的抽取顺序决定了用哪个实现。

我遇到过一次相当典型的：某个模块在头文件里声明了void reset(void)，两个不同的源文件各自提供了一个实现，其中一个打桩用的空实现还标了弱符号。结果链接顺序一变，空桩被抽进了最终产物，整个复位流程形同虚设，所有日志都在报"函数执行成功"，实际上什么都没做。nm -A *.o | grep reset把所有目标文件扫一遍就水落石出了。

4.3 把手头这几个工具用起来

不用记太多命令，掌握下面几条就够应付九成场景：

# 看单个目标文件里的符号，T/t 是已定义，U 是未定义引用，W 是弱符号 nm main.o # 跨多个文件搜索某个符号，输出带文件名，最实用 nm -A build/*.o | grep init_system # 反汇编，看调用点到底 call 到了哪个地址 objdump -d main.o | grep -A2 "call" # 看符号表里所有函数的地址和大小，判断函数是否真的存在 readelf -sW a.out | grep FUNC

nm的输出里那个字母很重要。T表示在代码段定义、全局可见，t表示局部（static）可见，U表示未定义、需要链接期解析，W是弱符号。如果你期待看到T却看到了U，说明链接阶段没找到实现；如果看到了t但你以为它是全局的，那就中了上一小节的招。

反汇编里call后面跟的地址，可以拿去对readelf输出的函数地址表，确认跳转目标。这一步做一遍，符号层面的问题基本无处遁形。

4.4 跨语言调用是最容易翻车的一段路

C++ 编译器会给函数做名字修饰（name mangling），void init()在 C++ 里可能变成_Z4initv这样一串。如果一边是 C 编译的调用方、一边是 C++ 编译的实现，链接器就会告诉你"未定义引用"，然后你盯着init这个名字看半天想不明白为什么找不到。

修法是在 C++ 那边用extern "C"包住声明：

#ifdef __cplusplus extern "C" { #endif void init(void); #ifdef __cplusplus } #endif

这段模板几乎每个跨语言头文件都该有，写一次管一辈子。忘了它的项目，会在某个深夜因为一个莫名其妙的undefined reference卡住。

调用约定的事也归在这一类。__cdecl和__stdcall的栈清理责任方不一样，函数指针类型不匹配时，程序可能在返回的瞬间崩掉，表现成"函数执行完了但回不来"。这类问题在 Windows 平台的二进制接口上格外常见，跟 Linux 的 System V ABI 完全是两套逻辑。

5. 调用语句被宏、条件编译和函数指针改写掉了

前面几章讲的都是"编译/链接阶段"的事情，这一章回到源码层面，但换了个方向：源码里确实写了调用，只不过在编译之前或者运行之中被换掉了。

5.1 宏与函数同名：预处理阶段的偷梁换柱

#define init() do { } while (0) void init(void) { /* 真正的实现 */ } int main(void) { init(); /* 展开成 do { } while (0)，实现压根没被调 */ return 0; }

预处理之后，init()变成了空语句，函数定义的void init(void)因为后面跟的是(void)而不是()，反而不受影响，所以编译链接一路绿灯。这种坑在引入某些"兼容层头文件"或者老版本 SDK 的时候特别容易踩——你根本不知道哪个头文件里藏了一个同名宏。

排查方法仍然是gcc -E，但这次要盯住展开结果里你的调用点变成了什么。gcc -E -dD会把宏定义也一并输出，方便对照是哪一处定义的宏在起作用。

反向的坑也存在：有人定义了一个宏，宏名和函数名相同但不带参数，#define init，那么所有init这个 token 都会被替换成后面的内容，连函数定义的函数名都会被换掉，报出来的语法错误能让人看傻眼。我在一次代码审查里就发现过这种写法，当时第一反应是编译器出 bug 了。

5.2#if分支和构建配置

这类问题在功能开关多的项目里几乎是常态。初始化代码被包在#ifdef HAVE_XXX里，构建系统没定义这个宏，代码就整段消失，连警告都不给。

void board_init(void) { #if defined(CONFIG_ENABLE_DMA) dma_setup(); #endif clock_setup(); }

CONFIG_ENABLE_DMA没开，dma_setup()就永远不会被调用，而这个函数在别处仍然被引用（比如中断处理），于是你会看到一堆"某个变量没初始化"的怪现象。

查这类问题的正确姿势是先看宏清单：gcc -dM -E - < /dev/null能打印出编译器预定义的所有宏，把你的构建参数加上再跑一次，就得到完整的宏集合。然后拿这个集合去和源码里的#if条件逐个对照，少哪个一目了然。CMake 项目还可以直接看compile_commands.json，每个文件的-D参数都躺在里面。

5.3 函数指针：调用了，但指向空壳

void (*handler)(void) = NULL; handler(); /* 解引用空指针 */

这种情况通常是段错误，不会表现为"函数没执行"，所以不属于易混淆项。真正容易混的是另一种：handler被赋了一个默认的空函数，注册流程没走完或者注册失败了，调用就静默地什么都没干。

我见过的真实场景是回调机制：上层注册on_ready回调，底层在事件发生时空调用。注册函数因为参数检查不严返回了成功但实际没存，on_ready的默认值是一个空的nop_handler。整条链路日志一应俱全，就是"业务函数没被执行"。这种坑只能靠给默认处理器加一条"未注册"的日志来暴露，光看代码看不出来。

5.4 短路求值和逗号表达式

if (0 && do_something());

&&有短路语义，左边为假，右边整个不执行。这类写法在调试开关里非常常见：if (debug_enabled && dump_state())，debug_enabled为假时dump_state一次都不会跑。有人专门把dump_state()放前面来"验证它是否被调用"，结果当然是没调用。

逗号表达式稍微反直觉一点：a, b;里两个表达式都会求值，整个表达式的值是b。所以prepare(), run();这种写法是真的会调用两次，别被某些人说的"逗号只执行最后一个"误导——那句话说的是返回值，不是求值。

三目运算符也归属这类：cond ? foo() : 0;里cond为假时foo不执行。用三目来做"条件调用"而忘记写 else 分支，是很常见的疏漏。

6. printf 没输出、断点是灰的：调试器和缓冲区怎么骗你

这一章对付的是"函数其实执行了，但你没观察到"的那一批问题。数量上它可能是最多的，因为几乎所有的 printf 调试法都要跟输出缓冲打交道。

6.1 stdout 的三种缓冲模式

C 标准定义了三种缓冲策略：全缓冲、行缓冲、无缓冲。默认情况下，stdout 连接到交互式终端时是行缓冲（遇到\n就刷），连接到文件或管道时是全缓冲（填满 4KB 左右才刷）。stderr则是无缓冲，永远立即输出。

这就解释了一个经典现象：程序在终端里跑得好好的，一重定向到日志文件就"丢"了一部分输出——因为进程在缓冲区刷盘之前崩溃了，缓冲区里的数据跟着进程一起没了。

想在调试期规避这个问题，两个办法。一是在main开头加一句：

setvbuf(stdout, NULL, _IONBF, 0);

强制改成无缓冲，代价是输出变慢，只适合调试期用。二是在每条printf后面加fflush(stdout);，粒度更细但更啰嗦。

顺带说一个相关的：如果你用fprintf(stderr, ...)做调试输出，反而看不到这个问题，因为 stderr 本来就无缓冲。很多老手习惯用 stderr 打调试日志，就是这个原因。

6.2 断点为什么是灰的

gdb 里断点显示为灰色或者带y前缀但打不上，通常意味着这个位置没有对应的机器指令。造成这种结果的原因有几个：

• 函数被内联进了调用者，源码里那一行没有独立的代码段。
• 编译时没加-g，或者加了但被strip掉了。
• 优化器挪动了指令位置，行号映射对不上。
• 整个函数被消除了（见第 3 章）。

排查顺序是先用-O0 -g3重新编译，确认在无优化的情况下断点能否打上。能打上，那问题就是优化导致的；打不上，就要往符号层面查了。

已经优化过的二进制也不是不能调试。info functions 函数名能告诉你这个函数在优化后是否还存在于符号表里，disassemble /m main会把反汇编和源码行混排显示，即使行号有偏移也能对应个大概。现代 gdb 对 inline 函数的支持已经不错，但依然不如-O0来得直观。

6.3 多线程和中断上下文的观测盲区

单线程程序里"执行了却看不见"主要是缓冲问题，到了多线程就多了一层时序问题。主线程设了标志位，工作线程还没轮到就退出了；或者工作线程里调用了一个函数，但那个函数依赖的初始化在另一个线程里还没完成。

中断上下文更麻烦。在中断处理函数里设断点，调试器停住的同时整个系统可能就死了（比如看门狗复位），你根本来不及看现场。这种情况下只能靠内存日志——在中断里往一块预分配的环形缓冲区写记录，退出中断后再 dump 出来。嵌入式开发里这是标准操作，桌面开发也一样适用，只是换成了写文件或者共享内存。

6.4 拿"硬证据"的几种办法

观测手段失效的时候，退回到最朴素的证据链：

第一，用volatile计数器。在函数入口g_enter_count++，程序跑完或者出异常之后打印它。只要计数涨了，函数就执行过，剩下的问题全归到观测链路上。

第二，在函数开头翻转一个 GPIO，用示波器或者逻辑分析仪看波形。这招在嵌入式里几乎是终极手段，因为它完全绕开了软件层面的所有中间环节——没有缓冲、没有调试器、没有优化干扰。波形出来了就是执行了，波形没出来就是没执行，没有第三种可能。

第三，用系统调用追踪。strace看系统调用，ltrace看库函数调用。如果你的函数内部调用了open、write、mmap这类接口，追踪结果里能看到就是执行过。这一招在怀疑动态链接库版本不一致的时候特别好用。

第四，在函数体里写一个全局的、非 static 的变量，运行完用nm和objdump检查它在二进制里的状态。这种方式比较笨重，但不需要任何运行时支持。

7. 我常用的六步排查顺序，从一分钟到十分钟

到这儿各类成因都摊开讲完了，最后给一份可以直接照着走的排查顺序。这套流程我用了很多年，原则是"低成本手段优先，一步能排除一大片就不做第二步"。

第一步价值最高，因为它同时排除了宏和语法两个大类，而且成本极低。我见过太多人跳过这一步直接上调试器，结果在断点打不上的问题里绕了半天。

第二步是关键分水岭。有call说明代码生成没问题，往链接和运行期查；没call说明调用在编译阶段就没了，往语法和优化查。这一刀切下去，问题域直接减半。

第三步处理"有 call 但跳错地方"的情况，nm的字母标记能告诉你符号是从哪来的、能不能被覆盖。第四步是绕过一切优化的干扰，把问题还原到最干净的形态。第五步和第六步是兜底，专门对付那些"其实执行了"的误报。

有一点要强调：这六步不是必须全走完。多数问题在前三步就定位了，后面的步骤只在前面无法定论时才用得上。我遇到的大部分"C语言 void 函数不执行"的报告，走到第二步就真相大白了。

最后分享一个习惯上的小建议。给初始化类的 void 函数在入口加一行带函数名的日志，看起来是废话，但在排查这类问题时它能瞬间把"没调用"和"调用了没效果"区分开。日志的开关做成编译期宏，Release 构建里关掉，Debug 构建里打开，成本几乎为零。这个习惯是我在某次连续加班到凌晨三点查一个初始化顺序问题之后养成的，之后再没在这类问题上浪费过超过半小时。