C语言的宏嵌套展开规则，说难不难，但翻起车来是真的让人挠头。早期我写日志库和断言工具时，被字符串化不展开、粘贴符粘连出错误标识符、宏套宏自己跟自己死锁这几个问题反复折腾，后来把预处理器的实际工作方式系统地捋了一遍，才发现大部分坑都来自同一套规则。这篇文章就围绕宏嵌套的展开规则，把一个宏里套另一个宏、参数里再套参数、以及#和##参与时的行为讲清楚。适合正在啃 C 语言进阶的人、写公共库和嵌入式代码的开发者，以及想彻底搞懂预处理器的朋友。
1. 先建立一套直觉：宏展开不是简单文本查找，而是“流式扫描”
1.1 两类宏：对象宏与函数宏
宏定义分两种，展开方式有区别。
对象宏是最简单的：#define N 100，之后出现N就替换成100。函数宏带参数：#define ADD(a, b) ((a) + (b))，调用时ADD(1, 2)会把a和b分别替换成1和2。
这里有一个容易忽略的触发条件：函数宏名后面必须紧跟(，中间不能有空格，否则不会被当作宏调用。
#define F(x) ((x) * 2) F(3) // 展开为 ((3) * 2) F (3) // F 后面不是紧贴左括号，F 不会被当作函数宏触发这段代码里第二行很容易让人迷惑：F不会被展开，最终传给编译器的是F (3)，大概率报错。嵌套宏里一旦出现这种情况，展开链条会断在半路。
1.2 预处理器的工作模型：见到就展开，展开完再看结果
宏展开有一个形象的工作模型：预处理器从左到右扫描预处理记号流，遇到宏名就停下，把宏替换为对应内容，然后从替换结果的位置继续扫描。重点在于，这个“继续扫描”不是只扫一遍，而是不断在替换结果里寻找新的宏名，直到当前范围内没有可展开的宏为止。
我跟不太熟预处理器的人解释时会说：它就像一条传送带，宏是一个个“贴纸机”，扫到触发条件就把当前一小段记号换成另一小段记号，然后接着往前走。嵌套宏之所以复杂，是因为替换出来的内容里可能又包含新的宏名，机器会继续换，换出来的内容里可能还有待换的内容，于是形成了一条链条。
这个“扫描 → 匹配 → 替换 → 继续扫描”的循环，是所有嵌套展开规则的基础。后面提到的参数展开、重扫描、自引用抑制，全都是在这个模型上演化出来的行为。
2. 嵌套展开的核心规则，逐条拆开看
2.1 函数宏的参数：先完全展开，再替换进替换列表
这是嵌套宏最重要的机制，没有之一。
C 标准规定：函数宏调用时，每个参数在替换进替换列表之前，会先作为输入流进行完整的宏展开，除非这个参数前面有#或后面有##。
举个例子：
#define M 100 #define ADD_ONE(x) ((x) + 1) ADD_ONE(M)M作为宏参数，在进入ADD_ONE的替换列表前，先被完整展开为100。所以最终结果是((100) + 1)，而不是((M) + 1)。
再看一个参数出现多次的场景：
#define DOUBLE(x) x + x #define N 10 DOUBLE(N) // 得到 10 + 10如果参数在替换列表中出现两次，这个“先完全展开”的动作就意味着展开结果会被插入两次，但内容是相同的。这里有个容易忽略的地方：如果参数本身是1 + 2这种表达式，它不会先计算成3，因为宏展开是记号级的操作，不是表达式求值。它只是把1 + 2这组记号插入进来，真正的计算发生在编译阶段。
2.2 替换列表重扫描：展开结果还要再过一遍筛子
参数全部替换进替换列表后，整个替换列表会被当成一段新的输入流重新扫描。这是嵌套宏能一层层“接力”的引擎。
#define G(x) ((x) * 3) #define F(x) G(x) #define NUM 5 F(NUM)处理过程是：
- 扫描到
F(NUM)，参数NUM先展开为5。 F的替换列表G(x)变成G(5)。- 对替换列表进行重扫描，发现
G(5)是函数宏调用，展开为((5) * 3)。 - 最终结果就是
((5) * 3)。
如果没有重扫描这一步，F(NUM)会停在G(5)，然后编译器看到G是个未定义标识符，直接报错。所以理解“重扫描”非常关键。
2.3 自引用抑制机制：为什么宏不会无限递归
宏定义写#define A A，展开时会无限递归吗？不会。C 标准有一套抑制机制：当一个宏正在展开过程中，它的名字会被临时标记为“禁用”。在禁用状态期间，如果展开结果里又出现这个名字，预处理器不会再次展开它。
我习惯用一个比喻：宏一旦开始展开，它的名字就被涂上了“蓝漆”。在整次展开完成之前，预处理器扫描到任何带蓝漆的名字都会直接跳过。等这次展开结束，蓝漆才擦掉。
来看经典的互引用：
#define A B #define B A展开A：
A被标记为禁用，替换为B。- 重扫描时看到
B，B开始展开，被标记为禁用，替换为A。 - 继续扫描看到
A，但此时A还处于禁用状态（从第一次展开到现在还没结束），所以不再展开。
最终结果是A，而不是无限循环。
这个机制对嵌套宏影响很大：如果你在替换列表里再次引用了正在展开的宏，它不会按你期望的那样再展开一次，而是原样留在结果里，编译时大概率报未定义标识符。
2.4#和##：参数展开的暂停键
#的作用是把参数直接转成字符串字面量，##的作用是把左右两边的记号粘成一个记号。这两者都有一个共同特点：处于它们作用范围内的参数不会先展开。
#define STR(x) #x #define CAT(a, b) a##b #define VALUE 10 STR(VALUE) // 得到 "VALUE"，不是 "10" CAT(VALUE, 2) // 得到 VALUE2，不是 102注意CAT(VALUE, 2)这里，两个参数都被##挡住了，不会展开成10和2，它们只是被原样粘贴成VALUE2这个记号。
但有一个微妙的后续：如果粘贴出来的记号本身是另一个宏的名字，重扫描阶段它仍然会被展开。
#define FOO 5 #define CAT(a, b) a##b CAT(FO, O) // FO 和 O 粘贴成 FOO，FOO 是宏，进一步展开为 5这是##经常让人困惑的一个点：粘贴时参数不展开，但粘贴后的结果还有机会继续展开。
2.5 间接名绕过：宏名可以换个马甲继续调用
宏的名字可以作为另一个宏的替换内容，这为嵌套展开增加了一层灵活性。
#define F(x) ((x) * 10) #define G F G(3)G的替换列表是F，参数是3。展开G后得到F，但这时后面还跟着原输入里的(3)。重扫描时发现F后面紧贴左括号，于是F作为函数宏被再次触发，最终结果是((3) * 10)。
这类例子揭示了一个关键点：一个标识符是不是“宏调用”，完全取决于它当前时刻是否满足“宏名 + 紧跟左括号”的条件。一层宏可以把另一个宏的名字推出来，再由后续文本补上括号，完成函数宏调用。
3. 五个“反直觉”案例，逐个手工推演
3.1 案例一：双阶层字符串化，为什么必须包两层
我早期写版本号字符串时踩过这个坑。
#define STR(x) #x #define VERSION 2 STR(VERSION) // 得到 "VERSION"本意是想得到"2"，结果却变成"VERSION"。原因很直接：STR的参数前面有#，参数不会先展开，所以VERSION被原样字符串化了。
解决办法是加一层间接宏：
#define STR(x) #x #define XSTR(x) STR(x) #define VERSION 2 XSTR(VERSION) // 得到 "2"推演过程：
XSTR的参数是VERSION，它的替换列表是STR(x)，参数没有#和##阻挡，所以VERSION先展开为2。- 替换后得到
STR(2)。 - 重扫描时
STR(2)触发，#把2字符串化，最终得到"2"。
这就是嵌套宏中“先展开再字符串化”的标准姿势。很多项目里的文件路径、编译时间、枚举名打印都依赖这个套路。
3.2 案例二：##前面的参数为什么不展开
再看连接符的场景。
#define VAR_NAME(x) var_##x #define INDEX 3 VAR_NAME(INDEX) // 得到 var_INDEX，不是 var_3##让INDEX不展开，原样粘在var_后面。但如果确实希望先把INDEX展开成3再拼接，该怎么办？
答案还是加一层：
#define CAT(a, b) a##b #define XCAT(a, b) CAT(a, b) #define INDEX 3 XCAT(var_, INDEX) // 得到 var_3推演：
XCAT的参数是var_和INDEX，其替换列表是CAT(a, b)，参数没有被#或##阻挡。INDEX先展开为3，所以变成CAT(var_, 3)。- 重扫描时
CAT的两个参数被##阻挡，此时已经是3和var_，直接粘成var_3。
这个“先展开再粘贴”的两级宏，在工程里非常常用，几乎所有需要动态拼标识符的场景都能见到。
3.3 案例三：嵌套函数宏的优先级陷阱
宏嵌套并不只是字符串和标识符的问题，运算符优先级同样会出幺蛾子。
#define SQUARE(x) x * x SQUARE(1 + 2)展开后是1 + 2 * 1 + 2，按照乘法优先，结果是5，跟期望的9相差甚远。解决办法是参数和整体都加括号：
#define SQUARE(x) ((x) * (x))嵌套时会怎么样？
#define SQUARE(x) ((x) * (x)) #define ADD(a, b) ((a) + (b)) SQUARE(ADD(1, 2))展开流程：
- 外层
SQUARE的参数是ADD(1, 2)。 - 参数先完整展开，
ADD(1, 2)变成((1) + (2))。 - 把这个结果替换进
SQUARE的替换列表，得到((((1) + (2))) * (((1) + (2))))。
因为参数层面已经加好了括号，插入后不会破坏优先级。这个案例提醒我们：设计带表达式参数的宏时，括号不是可选项，是必需品。
3.4 案例四：宏名自己跟自己死锁
交叉引用宏的结果往往超出直觉。
#define A B #define B A展开A的过程前面推演过，最终结果是A原样保留。预处理器没有爆栈，它只是把这个宏名“存起来”了。
这个机制在大型代码里很容易造成隐蔽问题。比如两个头文件各自定义了宏，名字相同或者互相引用，展开结果里残留一个未展开的宏名，编译器报错时给出的信息很难联想到这里。
我遇到过排查了很久的一个案例：某个项目里定义了
#define DEBUG LOG #define LOG DEBUG看起来很可怕，展开DEBUG后整条链在DEBUG处停住。最后用预处理输出一看，才发现这里有个交叉引用死锁。
3.5 案例五：宏名后面跟括号才算函数调用
函数宏的触发条件是“名字 + 紧跟左括号”，这决定了参数展开阶段不会主动展开孤零零的宏名。
#define CALL() 999 #define PASS() CALL PASS()()展开过程：
PASS的参数是CALL。注意这里CALL后面没有(，所以在参数展开阶段不会展开。PASS的替换列表是CALL，替换后得到CALL。- 重扫描后，原输入里剩下的
()还跟在后面，形成CALL()，于是CALL被触发，展开为999。
这个“晚一步展开”的特性，在一些延迟展开技巧中会被刻意利用，但如果不了解它，看到PASS()()这种写法会一脸茫然。
4. 工程实战：日志、断言、代码生成里怎么用才不翻车
4.1 日志宏的字符串化设计
现在看一个非常典型的日志宏：
#define LOG_INFO(fmt, ...) \ printf("[INFO] %s:%d: " fmt "\n", __FILE__, __LINE__, ##__VA_ARGS__)调用方写成LOG_INFO("count=%d", count)，fmt会被替换成字符串字面量"count=%d"，没问题。但如果调用方传的是一个宏名呢？
假设：
#define DEFAULT_FMT "count=%d" LOG_INFO(DEFAULT_FMT, count)参数DEFAULT_FMT在进入LOG_INFO前会先完全展开，变成字符串字面量"count=%d"，再替换进fmt。所以最终得到的是相邻字符串字面量拼接，合法。
这里能体会到“参数先完全展开”在工程里的实际价值：宏可以自动展开传入的宏名，而不用你手动去拆。
如果想把一个宏名变成字符串字面量，则需要上文的XSTR套路：
#define STR(x) #x #define XSTR(x) STR(x) #define MODULE_NAME analytics printf("module: %s\n", XSTR(MODULE_NAME));这个宏会先展开MODULE_NAME为analytics，再字符串化得到"analytics"。
4.2 可组合的版本号与名称生成
假设要生成一个版本字符串，同时保留数字宏以备计算：
#define VER_MAJOR 3 #define VER_MINOR 2 #define STR(x) #x #define XSTR(x) STR(x) #define VERSION_STRING XSTR(VER_MAJOR) "." XSTR(VER_MINOR)展开过程：
XSTR(VER_MAJOR)先让VER_MAJOR展开为3，再字符串化为"3"。- 同理
XSTR(VER_MINOR)得到"2"。 - 结果是
"3" "." "2"，编译阶段拼接成"3.2"。
如果直接把VER_MAJOR放进STR，就会得到"VER_MAJOR"，版本号直接变成一堆宏名，这是非常常见的失误。
类似的例子还有生成变量名：
#define CAT(a, b) a##b #define XCAT(a, b) CAT(a, b) #define VERSION 3 XCAT(g_version_, VERSION) // 展开为 g_version_3几乎所有需要“依据某个宏的值来生成新标识符”的场景，都会用到这个组合。
4.3 延迟展开技巧：手动控制扫描时机
借助空宏，我们可以刻意让某个宏的展开晚一圈发生。
#define EMPTY() #define DEFER(x) x EMPTY() #define FOO() 123 DEFER(FOO)()逐步推演：
DEFER(FOO)的参数是FOO，单独一个FOO后面没有(，参数展开阶段不会触发。DEFER的替换列表是x EMPTY()，替换后得到FOO EMPTY()。- 重扫描时
EMPTY()展开为空，当前替换结果只剩下FOO。 - 此时原输入里剩下的
()接上去，形成FOO()，再展开为123。
如果没有EMPTY的垫片，FOO在重扫描时可能已经被括号接住并提前展开了。这种手法常被用来设计更复杂的预处理“元编程”，但它会让代码可读性显著下降。我一般建议只在库内部使用，并且注释写清楚展开步骤，普通业务代码不要碰。
4.4 面向嵌套宏的设计规范
多年写宏下来，我给自己定了几个规则：
- 函数宏的替换列表里，参数出现的位置必须加括号，整体再加一层括号。
- 凡是需要“先展开参数再字符串化/拼接”的，一律用两级宏：
STR配XSTR，CAT配XCAT。 - 宏名统一加项目前缀，避免跨头文件互相同名、互相引用。
- 替换列表里不要直接引用正在展开的宏，也不要用 A 引用 B、B 又引用 A 的方式“互相帮忙”。
- 可变参数宏在参数可能为空时，用
##__VA_ARGS__处理逗号问题，这是 GNU 扩展，C++20 之后可以用__VA_OPT__。 - 超过两层的宏嵌套，先手动展开一遍再写进头文件，别让队友帮你踩雷。
5. 调试方法：把“展开后长什么样”直接掏出来看
5.1 预处理结果查看的三种方法
宏嵌套问题靠肉眼盯代码很容易看走眼，最直接的方法是让编译器输出预处理结果。
命令行下加-E选项，只做预处理不编译：
gcc -E -P test.c clang -E -P test.c-P的作用是去掉行号标记，输出更干净。如果只想看宏定义本身，可以加-dM：
gcc -dM -E -P test.c这个命令会把当前环境下所有已定义的宏列出来，排查宏冲突时非常好用。在常用的 IDE 里，一般也都有“预处理”或“生成预处理文件”的按钮，输出文件通常以.i结尾。把生成的文件打开，看看对应宏的展开结果，问题往往一眼就能发现。
5.2 常见问题速查表
| 现象 | 根本原因 | 解决办法 |
|---|---|---|
字符串化得到宏名，比如"VERSION"而非"2" | #阻止参数展开 | 加一层XSTR(x) STR(x)间接宏 |
拼接结果缺少实际值，比如var_INDEX而非var_3 | ##阻止参数展开 | 加一层XCAT(a,b) CAT(a,b)间接宏 |
| 宏套宏后残留宏名，编译报未定义 | 交叉引用触发自引用抑制，宏被“涂蓝” | 避免循环引用，排查宏名冲突 |
| 运算结果和预期不符 | 替换列表缺括号，优先级被破坏 | 参数和整体都加括号，必要时包两层 |
| 可变参数宏传空参数导致编译报错 | __VA_ARGS__为空时尾巴上多了逗号 | GNU 扩展##__VA_ARGS__或 C++20 的__VA_OPT__ |
| 函数宏名传参后没有按预期展开 | 参数阶段没形成“宏名+左括号”的调用形态 | 检查调用是否带括号，或借助重扫描机制 |
5.3 我踩过的几个坑总结
第一个坑是直接对数字宏用STR，得到一个带引号的宏名，当时在日志模板里打印半天都是LEVEL而不是3。第二个坑是想把两个宏拼成新宏名，结果拼出一个带宏名的标识符，编译器报“未声明的标识符”时我完全没往预处理方向想。第三个坑是交叉引用宏，展开结果里出现一个看起来不该存在的宏名，最后靠预处理输出才定位到。
这些经历让我养成了习惯：只要宏的展开结果不符合预期，第一件事不是改代码，而是看预处理输出。绝大多数嵌套宏问题，在.i文件里都藏不住。
我个人在实际操作中的体会是：宏嵌套的规则不需要死记硬背，理解“扫描、替换、重扫描、涂蓝抑制”这条主线之后，剩下的都是它的推论。写嵌套宏时多留一步心：参数要不要先展开，结果会不会被再扫一次，名字会不会撞车。花五分钟推演一遍，比用一整天调试展开后的奇怪符号省心得多。
