企业官网建设流程全解析

1. 编译之前那一步：#include 到底做了什么

1.1 预处理器干的活，本质上是"文本整理"

很多人背过"编译分四个阶段：预处理、编译、汇编、链接"，但真正写代码的时候，脑子里只有"写 .c、点编译、跑程序"这三件事，中间那一步被完全忽略。等到某天项目里冒出一个莫名其妙的redefinition of 'struct xxx'，或者某个函数明明写了却报"未定义引用"，才开始回头翻这一块。

我的经验是：把预处理命令和 #include 当成一门独立的"文本编辑语言"来学，而不是当成 C 语法的一部分，理解速度会快很多。它不认变量、不认类型、不认作用域，它只认一行一行的字符，以及以#开头的那些指令。预处理器的全部工作可以概括成四件事：把注释换成空格、处理续行符、做条件编译、做文件包含和宏替换。做完这些，输出一份被撑大的纯文本，再交给真正的编译器。

这个认知非常重要，因为它解释了一大堆"反直觉"的行为。为什么头文件里写错一个符号，报错行号会指向一个你从没打开过的.h文件？因为那段文本已经被物理地拼进了你的.c文件里。为什么宏定义里少写一层括号会算出离谱的结果？因为宏替换发生在编译之前，编译器看到的已经是你手写的那堆字符，根本没有"参数求值"这个概念。

用一个日常类比：预处理就是"排版前把几个文件复印粘贴成一份长文档"。你的.c是主文档，.h是从别处剪贴进来的段落。剪贴的时候不做任何校对——贴进来之后，标点冲突、重复段落、错别字，才会被后面的编辑（编译器）发现。报错当然只会出现在合并后的长文档里。

1.2 一份被撑开的代码，长什么样

理论说一百遍，不如直接看一眼。建两个文件，一行代码不加，只留包含关系：

/* math_utils.h */ #ifndef MATH_UTILS_H #define MATH_UTILS_H #define SQ(x) ((x) * (x)) int add(int a, int b); #endif

/* main.c */ #include "math_utils.h" int main(void) { return add(SQ(3), 4); }

用gcc -E main.c -o main.i展开，你会看到main.i里#include那一行消失了，取而代之的是math_utils.h的全部内容，注释被替换成空格，空行可能保留，SQ(3)被替换成((3) * (3))。整个文件末尾还跟着编译器内置的一大堆 typedef 和声明，那都是从标准库头文件里粘过来的。

这一步能看出来的东西比想象中多：

• 头文件的物理内容会被完整复制，所以头文件写得越臃肿，每个包含它的.c就越胖，编译越慢。这是后面讲编译时间优化时的根本原因。
• 宏替换是"纯字面替换"，SQ(3)变成((3) * (3))，注意外层括号是宏定义里自己写的，不是预处理器加的。少写一层，2 / SQ(3)就会变成2 / 3 * 3，结果完全不同。
• 行号信息被保留，编译器报错时能指出原始文件和行号，靠的是预处理输出里的行标记机制，这也是为什么报错位置通常还算准确。

提示：-E只是最基础的一步。想看清楚"到底包含了哪些头文件、按照什么顺序、各自被包含了多少次"，用-H更直观，这个问题在第 6 节展开。

1.3 为什么这一章值得单独拿出来讲

我见过太多人，包括工作两三年的开发者，对#include的理解停留在"要用 printf 就 include stdio.h"。这种理解在单个文件里完全够用，一旦工程扩张到几十上百个源文件，就会连环出事。

具体会出什么事？举几个我实际遇到过的：头文件互相包含导致的结构体未定义；在头文件里顺手写了个全局变量，结果链接器报几十个重复定义；#pragma once在某些复制粘贴的头文件上失效，因为两个不同目录下的文件内容相同但路径不同；条件编译宏在 Debug 和 Release 下表现不一致，本地跑得好好的，打出来的包里功能没了。

这些问题的共性是：它们都不会在写代码的那一刻暴露，而是在某个更晚、更远的环节炸开。预处理阶段的错误具有强烈的延迟性，所以必须主动建立正确的模型，而不是等着踩坑之后再补。下面的内容会按照"包含规则 → 防重机制 → 该放什么不该放什么 → 宏与条件编译 → 工具化调试"的顺序展开，每一步都给出可操作的做法和踩过的坑。

2. 尖括号与双引号：差别远不止"系统"和"本地"

2.1 搜索顺序的真实规则

几乎所有入门资料都说：<...>用于系统头文件，"..."用于自己写的头文件。这句话不算错，但它省略了最关键的信息——具体的搜索顺序。而所有的"头文件找不到"和"找到错的那一个"，都源于对这个顺序不清楚。

以 GCC/Clang 系编译器为例，两种写法的搜索链条大致是这样：

从表里能读出两个关键点。第一，双引号写法多了一步"当前文件所在目录"，所以你在项目里写#include "config.h"能直接找到同目录的文件，而#include <config.h>找不到。第二，-I在两种写法里都生效，而且都排在内置系统目录之前，这意味着你自己加的一个目录里的stdio.h，会顶掉系统的那个。

第二点不是理论推演。我在一个中型项目里遇到过：某个第三方库的目录被整个加进了-I，里面恰好有一个叫types.h的文件，而项目代码里大量使用#include <types.h>。加进去的当天，一堆平台相关的类型定义就开始报错，报错位置在系统头文件内部，看起来像是编译器出了问题。排查了半天才定位到是搜索路径顺序被自己改了。这类问题的排查成本极高，因为报错现场和事故源头隔着好几层包含。

2.2 相对路径与"当前目录"的陷阱

双引号写法里的"当前源文件所在目录"这一条，在实践中还有一个容易误解的细节：它是相对于当前被处理的文件，而不是相对于工程的根目录。也就是说，如果a.c包含了sub/b.h，而b.h里又写了#include "c.h"，那么编译器会去sub/目录下找c.h，而不是去a.c所在的目录找。

这个行为大部分时候是对的，但会让一种写法变得很脆弱：头文件里写#include "../include/xxx.h"这种基于目录层级的相对路径。一旦头文件被移动到别的位置，或者在别的目录下被包含，路径就断了。我的建议是头文件里一律不写跨目录的相对路径，所有跨目录引用都走-I加上从某个固定逻辑根开始的路径，比如#include "core/config.h"，然后在构建脚本里把core的父目录加进-I。这样目录结构调整时只需要改构建脚本一行，不用全工程搜替换。

还有一个更隐蔽的坑：如果构建脚本里的-I加的是相对路径（比如-I include），那么它相对于执行编译命令时的工作目录，而不是 Makefile 所在的目录。很多构建脚本在顶层目录跑没问题，一旦被嵌入到别人的脚本里，工作目录变了，-I就指向了别处，报错是"找不到头文件"，而文件明明在那里。我的习惯是构建脚本里统一转成绝对路径，或者干脆用构建系统提供的路径变量，避免手写相对路径。

2.3 一个真实的"同名头文件顶掉"案例

说一个比较典型的场景。模拟项目 X 里有两个模块，一个是设备通信层，一个是数据解析层，各自维护了一份protocol.h。开发者在parser.c里写：

#include "protocol.h"

他以为拿到的是解析层目录下的那份，实际上因为构建脚本把通信层目录的-I加在了前面，编译器先搜到了通信层的那份。两份文件里都定义了同名的结构体，但字段不同。结果编译通过，运行起来字段错位，解析出来的数据全是乱的。

这类问题的排查路径我总结成三步：先用-H确认实际包含的是哪个物理文件（后面会讲具体用法），再检查构建脚本里的-I顺序，最后决定是改路径还是改文件名。根本的解决办法是给头文件起全局唯一的路径前缀，比如device/protocol.h和parser/protocol.h，从写法上就杜绝混淆。同名头文件在小型项目里很常见，在多人协作的项目里是定时炸弹。

3. 头文件保护：重复包含到底炸在哪

3.1 没有保护时，编译器报的错长什么样

先还原一下没有头文件保护时的现场。假设point.h里定义了一个结构体：

/* point.h */ struct point { int x; int y; };

main.c包含了两遍：

/* main.c */ #include "point.h" #include "point.h" int main(void) { return 0; }

编译结果：

point.h:2:8: error: redefinition of 'struct point'

这条报错的关键信息是：同一个结构体在同一个翻译单元里被定义了两次。注意 C 语言里结构体的重复定义是硬错误，不像函数声明那样可以重复写。

那为什么真实项目里会产生"重复包含"？因为包含关系是可传递的。a.c包含b.h和c.h，而b.h和c.h都包含了point.h，于是point.h在a.c里出现了两次。这种情况下，你在a.c里根本看不到任何可疑的重复，问题完全藏在两颗二级头文件里。项目越大，包含关系越复杂，出现这种重复的概率越接近 1。

有意思的是，函数声明重复是合法的，变量声明重复也是合法的，所以一个头文件里如果只有函数声明，重复包含不会报错。这就是为什么有些团队的头文件一直没加保护却"好像也没事"——直到某天有人在里面加了一个结构体定义或者一个宏，整棵树就开始报错。这种延迟暴露的特性让它非常危险，保护必须从一开始就写。

3.2 include guard 与 #pragma once 的取舍

两种做法，各有明确的适用面。

第一种，标准做法，宏保护：

#ifndef PROJECT_CORE_POINT_H #define PROJECT_CORE_POINT_H struct point { int x; int y; }; #endif /* PROJECT_CORE_POINT_H */

原理很朴素：第一次进来时宏未定义，定义它，然后把文件内容输出；第二次进来时宏已定义，整块内容被条件编译吞掉。注意三件事必须对齐：#ifndef判断的宏名、#define定义的宏名、#endif后面注释里的名字，三者不一致就会出现"保护看起来写了但没生效"的诡异情况。宏名必须全局唯一，我习惯用"工程名_目录层级_文件名_H"的格式，全大写，下划线分隔。

第二种，非标准扩展，但主流编译器都支持：

#pragma once struct point { int x; int y; };

两行变一行，不用想宏名，语义也更直接——"这个物理文件只包含一次"。它解决的问题比 include guard 更彻底的地方在于：基于文件路径判重，而不是基于宏名。这意味着即使两个文件内容一模一样但路径不同，#pragma once也不会把它们混淆；反过来，同一个文件通过软链接或不同路径被包含时，#pragma once的行为依赖编译器的路径规范化实现，早期版本存在识别不出的情况。

两者的对比：

我的实际做法是：新项目统一用#pragma once，需要兼容非主流编译器或跨平台要求严苛的模块用 include guard。有些团队为了省事两个都写，其实没必要，反而增加了维护噪音。如果必须二选一且不确定目标编译器，选 include guard，标准性是硬通货。

3.3 容易翻车的两个细节

第一个细节：guard 宏名重复。这种事情发生在复制粘贴的时候。新建头文件时所有人都是复制上一个文件改内容，忘了改宏名，两个头文件用了同一个保护宏。现象是：先被包含的那个正常，后被包含的那个内容凭空消失，编译器报"未定义的类型"。这种错误极其难查，因为报错位置和问题头文件完全没有关系。防住的唯一办法是把 guard 宏名写进代码评审的检查项，或者用工具自动生成头文件模板。

第二个细节：#endif位置写错。保护宏的#endif一定要放在文件最末尾，而不是某个结构体后面。曾经见过有人把#endif写在前面几行，后面还有一大段内容，导致后半段完全不受保护。预处理阶段不报任何错，编译也过，只在特定包含顺序下才暴露问题。

提示：#pragma once对"内容相同但物理路径不同"的两个文件不生效。如果项目里有从公共库复制粘贴过来的头文件，务必确认 guard 宏是否也一并复制，这是最高频的翻车点之一。

4. 头文件里能放什么：定义、声明与"刚好能编过"的错觉

4.1 能编译通过，不等于没问题

先把最容易出事的一条放在最前面：在头文件里定义变量或函数（非 inline），是典型的"单个文件编译通过、整个工程链接失败"。原因在于头文件会被复制进每一个包含它的翻译单元（TU），每个.c都有一份完整的定义，链接器合并时发现同一个符号有多个强定义，直接报重复符号。

/* 错误示范：bad.h */ int g_counter = 0; /* 定义，不是声明 */ void do_something(void) { } /* 定义，不是声明 */

只要有超过一个.c包含这个头文件，链接阶段必然失败。而如果只有一个.c包含它，工程能正常构建，于是这种写法可能潜伏很久，直到某天第二个文件也需要用这个功能。判断标准很简单：头文件里只应该出现"声明"，以及被语言规则允许重复出现的"定义"。

那什么定义放头文件里是安全的？给个清单：

4.2 static 与 const 在头文件里的语义陷阱

static全局变量放头文件里，是很多人的第一反应："这样每个文件都能用，而且不会链接冲突"。链接确实不冲突，但每个翻译单元各有一份独立的副本，互不共享。曾经有个模块用static数组在头文件里做配置表，本意是全局共享一份，结果某个.c修改了它，另一个.c读到的还是初始值，行为极其诡异。这类问题在单文件调试时完全看不出来，只有联调才暴露。

const在 C 里更微妙。C 语言中，文件作用域的const变量默认是外部链接（这一点和 C++ 相反，C++ 里const默认内部链接）。所以：

/* config.h */ const int MAX_RETRY = 3; /* C 里这是定义，多 TU 包含会重复定义 */

正确写法是声明加定义分离：

/* config.h */ extern const int MAX_RETRY; /* config.c */ const int MAX_RETRY = 3;

或者用枚举代替整型常量，用#define代替简单标量。这两种做法不产生符号，自然没有链接问题。宏的方式简单粗暴但失去了类型检查，枚举则兼顾类型安全与零开销，整数常量我优先选枚举。

inline函数是 C99 引入的，语义比想象中绕。简单记结论：头文件里的inline函数需要在某个.c里提供一个外部定义（通常是用extern inline或者在某个源文件里不加inline再写一遍），否则在某些编译模式下可能出现未定义引用。如果嫌麻烦，直接用static inline，代价是每个 TU 一份代码副本，对小型工具函数完全可接受，而且不会有链接问题。

4.3 前置声明能不能替代 #include

能，而且在减少编译依赖上非常有效。原理是：如果头文件里只需要用到某个类型的指针或引用，编译器不需要知道这个类型的完整定义，只需要知道有这么个名字。

/* 不需要 #include "device.h" */ struct device; /* 前置声明 */ int device_open(struct device *dev);

这样写的好处很实在：device.h里改了一行，所有包含它的文件不用重新编译。在大工程里，这种"减少不必要的包含"是编译时间优化最有效的手段之一。

代价和限制也必须说清楚：前置声明只适用于指针、引用和函数参数。一旦需要sizeof、访问成员、定义该类型的对象，就必须拿到完整定义。另外，过度使用前置声明会让头文件的"自包含性"变差——别人单独包含这个头文件时，可能因为缺类型定义而编译不过。我的平衡点是：头文件自身必须能独立编译通过，在这个前提下，能用前置声明减少依赖就用。判断方法很简单，把头文件单独拿出来编译一次，能过就说明它是自包含的。

还有一个实践中的纪律：每个.c文件的第一条#include应该是它自己对应的头文件。这样做的目的是强制验证头文件的自包含性——如果foo.h依赖了某个它没包含的头文件，把foo.c里的#include "foo.h"放第一位，编译立刻就会报错。如果放在后面，前面已经包含过依赖了，问题就被掩盖了。这条规则我很早就开始执行，抓出过好几个隐藏的包含缺失。

5. #define 与条件编译：威力大，坑也深

5.1 带参宏的括号纪律

带参宏是预处理命令里最容易出事的一类。核心原因还是那句话：纯文本替换，没有求值顺序，没有类型，没有作用域。

#define SQUARE(x) x * x /* 错误示范 */ SQUARE(2 + 3) /* 展开为 2 + 3 * 2 + 3 = 11，而不是 25 */

正确写法是两层括号，参数一层，整体一层：

#define SQUARE(x) ((x) * (x))

为什么两层都要？参数括号保证传入表达式作为一个整体参与运算，整体括号保证这个宏在更大的表达式里不被优先级破坏，比如SQUARE(a) + 1如果没有外层括号，会被展开成(a) * (a) + 1，虽然这个例子刚好没问题，但换成2 * SQUARE(a)就会出错。

括号解决了优先级，解决不了重复求值：

#define MAX(a, b) ((a) > (b) ? (a) : (b)) int i = 0; int m = MAX(i++, 10); /* i++ 可能被执行两次 */

如果i++ > 10成立，三元表达式的两个分支可能都会让i自增，最终i增加了两次。这类 bug 在调试时极难复现，因为结果依赖比较的两边到底谁大。结论是：带副作用表达式的参数不能传给宏，或者干脆改用static inline函数，让编译器去做类型检查。现代 C 里，能写成static inline的就不该写成宏，宏只保留给需要字符串化、记号拼接、或者必须接受任意类型且无法用函数表达的场景。

5.2 do { } while (0) 这个怪写法到底防什么

多语句宏必须包裹在do { ... } while (0)里，这是 C 语言里最著名的惯用法之一。为什么不用花括号直接包？

#define LOG_AND_RETURN() { printf("log\n"); return; } if (cond) LOG_AND_RETURN(); else do_something();

展开后if后面跟的是一个语句块，而;单独成了一条空语句，else就悬空了，编译直接报错。do { } while (0)展开后整体仍然是一个语法上完整的语句，末尾需要加分号，语义上和函数调用一致，可以安全地放在任何单条语句的位置。

这个写法的历史包袱很重，但至今仍是 C 语言宏的标准做法。使用的时候还有一个细节：宏定义内部如果声明了变量，要避免和外层作用域的变量重名，最好加上模块前缀。虽然do { } while(0)造了一个新的块作用域，但宏参数展开后仍然可能和内部变量冲突。

5.3 条件编译：好用，但容易把代码切成迷宫

条件编译的使用场景主要三类：平台差异、调试开关、功能裁剪。写法上有几个必须掌握的点。

#ifdef X和#if defined(X)效果相同，但在组合条件时后者更灵活：

#if defined(PLATFORM_A) && !defined(DISABLE_FEATURE_X) /* ... */ #endif

一个高频的坑是#if里写了不能求值的东西。预处理器只能处理整数常量表达式，sizeof、强制类型转换、浮点数、字符串比较全部不可用。写#if VERSION > 1.5会直接报错，因为1.5不是整数。版本号比较应该用整数编码，比如#if VERSION_MAJOR > 1 || (VERSION_MAJOR == 1 && VERSION_MINOR >= 5)。

另一个坑是宏的"定义"与"值"混淆：

#define FEATURE_FLAG 0 #ifdef FEATURE_FLAG /* 这里的代码会被编译，因为 FEATURE_FLAG 已被定义 */ #endif #if FEATURE_FLAG /* 这里的代码不会被编译，因为值为 0 */ #endif

#ifdef只判断"有没有定义"，不判断值。用-DFEATURE_FLAG=0在命令行定义它，#ifdef依然为真。这种不一致在构建系统里非常容易造成"我明明关了开关为什么功能还在"。我的规范是：功能开关一律用#if加明确的 0/1 值，不用#ifdef判断开关状态，#ifdef只用于"这个平台/这个头文件是否存在"这类存在性判断。

条件编译另一个隐性代价是可读性。当嵌套超过三层，代码会变成一片片互相排斥的孤岛，任何一次修改都要在脑子里维护一棵条件树。我的做法是：能用运行时判断的地方不要用编译期判断，条件编译只留给真正影响二进制产物的情况（比如某个平台根本没有这个系统调用）。功能开关尽量收敛到一个配置头文件里，不要在业务代码里散落到处都是#ifdef。

5.4 # 与 ## 的两个实用场景

#把宏参数转成字符串，##把两个记号拼成一个。这两个运算符平时用得少，但特定场景下能省掉大量重复代码。

#define STR(x) #x #define XSTR(x) STR(x) STR(hello) /* "hello" */ XSTR(__LINE__) /* "42"，而不是 "__LINE__" */

为什么要两层？因为#的操作数不会被展开，直接字符串化。想拿到宏的实际值，必须经过一层间接展开：外层XSTR先展开参数，再交给内层STR字符串化。这个技巧在打印宏值做调试时非常有用。

##的典型用法是自动生成函数名，比如为一组相似类型生成统一接口：

#define DECLARE_ACCESSOR(type, name) \ type get_##name(void) DECLARE_ACCESSOR(int, count); /* 展开为 int get_count(void) */

用它可以省掉大量手写的样板声明。但代价是调试体验变差：断点打不进去（因为预处理后名字才生成），静态分析工具也可能看不懂。我的原则是这类技巧只在"重复度高、逻辑极简"的地方用，任何带业务逻辑的东西都老老实实手写。

6. 把预处理"看见"：几个真正能救命的调试手段

6.1 展开结果怎么看，看什么

排查预处理相关的问题，第一步永远是"看展开后的结果"，而不是盯着源码猜。gcc -E source.c -o source.i是最基础的手段，source.i就是编译器真正看到的东西。看的时候重点看三样：

第一，宏展开后的表达式是否符合预期，尤其是带参宏和嵌套宏。第二，条件编译实际走了哪个分支，#if分支消失后剩下的代码是不是你想要的那份。第三，头文件内容是否完整地出现在该出现的位置。

有一点需要注意：-E输出会保留# 行号 "文件名"这样的行标记，别被它干扰，它只是给编译器和调试器用的位置映射。搜索的时候直接搜你的函数名或结构体名更快。

如果输出太长，可以只展开不包含：gcc -E -P -fdirectives-only之类的组合能让输出更接近原始结构。实际使用中，我更多是配合grep定位，比如gcc -E main.c | grep -n "struct point"，直接看这个结构体被展开了几次、在哪些位置。

6.2 谁包含了谁：-H 和依赖生成

gcc -H source.c会把整个包含树打印出来，每行前面用点的数量表示层级，最重要的信息是同一个头文件被包含了多少次，被重复包含的会加特殊标记。这个工具在排查"头文件重复包含"和"编译太慢"时效率极高。

gcc -H -c main.c -o main.o

输出大致是这样的层级结构：

. /usr/include/stdio.h .. /usr/include/features.h ... /usr/include/sys/cdefs.h . main.h .. common.h

配合-M或-MM可以生成 Makefile 格式的依赖文件，这也是自动处理"头文件改了要重新编译"的标准做法。手写 Makefile 时最常犯的错就是只写.c到.o的规则，没有写头文件依赖，导致改了头文件不重新编译，跑出来的还是旧代码。加上-MMD -MP让编译器自动生成依赖文件，然后include进来，这个问题一劳永逸地解决。

-MMD生成依赖文件时不包含系统头文件，-MP为每个依赖生成一个空目标，防止删掉头文件之后 Make 报错。这两个参数一起用是工程标配。

6.3 编译时间都花在哪：从包含树找答案

编译慢的原因，绝大多数情况下不是代码本身复杂，而是头文件包含树太胖。一个.c文件如果间接包含了上千个头文件，预处理阶段就要处理几十万行文本，这个开销每个文件都要付一遍。

优化手段按性价比排序：

第一，减少不必要的包含。头文件里用前置声明替代包含，用extern声明替代包含，只在.c里包含真正需要的东西。这一条往往能砍掉一半以上的包含量。

第二，检查是否存在"一个总头文件包含所有头文件"的做法。有些项目有个all.h或者common.h，把所有东西都塞进去，每个.c都包含它。这在早期很方便，工程一大就是灾难。拆分的成本不高，收益很明显。

第三，合理使用预编译头文件。把那些庞大且几乎不变的系统头文件集合预编译成二进制，后续编译直接复用。代价是构建系统复杂度上升，增量编译时如果预编译头本身变了会触发全量重建。我的判断标准是：单个.c的编译时间超过几秒，且包含树里有稳定的重型依赖，才考虑上预编译头。

第四，定期用工具检查"包含了但没用到"的头文件。有一些工具可以分析源码实际使用的符号，反推哪些包含是多余的，并给出删除建议。这类工具接进 CI 之后，能持续防止包含关系悄悄膨胀。

6.4 几个我踩过之后固定下来的习惯

分享几个具体习惯，都是踩坑之后养成的。

头文件第一行就写保护，不要等到出问题再加。新建头文件的模板里固定好#pragma once或者 guard 骨架，减少手写。

头文件里绝对不写变量定义和函数定义，需要共享的数据用extern声明放头文件，定义放唯一的.c。这条规则执行得越严格，链接期问题越少。

每个.c的第一条包含是对应的.h，验证自包含性。第二条开始放标准库头文件，然后是本项目头文件，最后是第三方头文件。这个顺序的好处是缺失的包含会尽早暴露，而不是被前面的包含意外掩盖。

宏定义全部大写并加模块前缀，带参宏的参数和整体都加括号，多语句宏用do { } while(0)。凡是能写成static inline的，不写宏。

条件编译只用于平台差异和构建裁剪，功能开关统一收敛到一个配置头。#ifdef只做存在性判断，值判断一律用#if。

排查任何"莫名其妙"的编译问题，第一步跑-H和-E，先确认编译器到底看到了什么，再回头改代码。这个习惯帮我省下的时间，比任何静态分析工具都多。很多看起来像编译器 bug 的现象，展开一看，问题就在自己写的某一行包含或者某个宏上。