先抛个问题：你写过#define吗？如果现在有人问你“#define到底是怎么替换的，替换之后程序又是怎么运行的”，你能答到哪一层？
这个问题我印象特别深。早年间我写过一个#define SQUARE(x) x*x，然后满怀信心地调用SQUARE(3+1)，结果输出是 7 而不是 16。当时的我翻遍了教材，只找到一句“宏定义是简单的文本替换”，可“简单”两个字压根解释不了为什么3+1会算成 7。后来我用编译器的预处理输出功能，亲眼看到宏展开前后代码的变化，才算真正把“文本替换”这四个字吃透。
这篇文章就把两件事讲透：#define是怎么替换的，以及替换之后的代码是怎么被编译、运行起来的。文章不会讲太偏的边角料，重点放在任何写 C/C++ 的人都会遇到的展开规则和经典坑上。适合刚接触 C/C++ 不久的同学，也适合写了很多年代码但一直没深究过预处理细节的开发者。
1. 先给#define找个“工位”：它在编译流程的最前端干什么
1.1 一条编译命令背后有四段旅程
在 C/C++ 里，我们平时说的“编译”，其实是一条流水线的总称。拿最简单的代码来说：
#include <stdio.h> #define THREE 3 int main(void) { int x = THREE; printf("%d\n", x); return 0; }这段代码变成可执行文件，中间至少经过四个阶段：
- 预处理阶段：处理所有以
#开头的指令，输出“纯净”的 C 代码。 - 编译阶段：把预处理后的 C 代码翻译成汇编语言。
- 汇编阶段：把汇编代码翻译成机器指令，生成目标文件。
- 链接阶段：把多个目标文件和库合并成最终可执行文件。
#define的“工位”就在第一阶段。它在预处理时完成替换，之后那行#define本身就被删掉了，后续的编译、汇编、链接阶段完全看不到宏的存在。也就是说，宏只是写给“预处理程序”看的一张便签，便签用完就撕。
很多人会把宏和“运行时的常量、函数”混在一起，根子就在于没分清预处理阶段和运行阶段。先记住一句话：#define的工作在程序运行之前就结束了，而且是远远地结束了。
1.2 为什么系统要单独留出预处理这个环节
从必要性角度追问，预处理有这么几个不可替代的作用。
第一是头文件包含。#include必须把头文件内容原样插入源文件，这件事得在语法分析之前做，否则编译器连printf的声明都看不到。
第二是条件编译。同一份代码要在不同平台、不同配置下编出不同版本，只能靠预处理阶段先“裁剪”代码。比如根据是否定义过某个宏，决定保留哪一段代码。
第三是宏替换。宏本质上是“在编译前生成代码”，是一种最原始的代码生成手段。#define把一个记号记成另一串记号，后面用到时直接把定义贴过去。
理解了这三点，你就明白为什么现在的编译器已经很强大了，预处理阶段却依然被保留下来。宏不会出现在运行时的任何环节里，它只存在于编译之前的文本世界。
2. 替换的真实规则：宏认的是“词”而不是“字符串”
2.1 预处理是基于“预处理记号”的替换
很多人理解的“文本替换”是：把整个源文件当字符串，找到宏名就替换成定义内容。这个理解差得有点远。
C 标准规定，预处理阶段的操作对象是“预处理记号”（preprocessing token）。这是什么概念？编译器扫描代码时，会先把源代码切成一个个最小单元：标识符、数字常量、字符串字面量、运算符、标点符号，每块都是一个独立的记号。
#define MAX 100 int a = MAX;上面这段代码被切成的记号大致是：int、a、=、MAX、100、;。预处理要做的是：找到MAX这个标识符记号，把它整个替换成100这个数字记号。a、=、;等记号完全不受影响。
“记号级替换”这个特点，直接带来三个新手常犯的错误认知：
"MAX"是一个字符串字面量记号，里面的字符不会被当成宏名。所以printf("MAX");打印出来的依然是MAX，不是100。// MAX 是一个常量这行注释里的MAX同样不会被替换。注释在预处理早期就被剥离了，宏展开根本轮不到它。MAX_VALUE是一个完整的标识符记号，即使定义过#define MAX 100，它也不会被替换。因为宏名必须以完整记号的身份出现，不能是另一个记号的一部分。
换句话说，宏替换不是你在编辑器里按 Ctrl+H 做全局字符串查找，而是“记号对记号”的精准替换。这个区别是后面所有坑的总根源。
2.2 宏展开不是一步到位：递归展开与防递归规则
宏展开不是一次性完成就收工的。如果展开结果里又出现了其他宏名，预处理会继续展开。比如：
#define A B #define B C int x = A; // A → B → C，最终得到 C但这里有一条非常重要的限制：在展开某个宏的过程中，如果展开结果里再次出现这个宏本身，它不会被再次展开。这是为了防止无限递归。
#define A A int x = A; // 展开一次得到 A，但 A 不会再展开两个宏互相引用时也是类似逻辑，预处理程序会给“正在展开”的宏打上标记，碰到标记就直接跳过。这条规则平时不太容易触发，但理解它，能帮你读懂一些奇怪的展开结果。
2.3#字符串化和##拼接：宏的“文本”本色
在带参数的宏里，还有两个特殊操作符：
#define STR(x) #x #define CAT(a, b) a##b char* s = STR(hello); // 展开为 "hello" int CAT(my_, var) = 1; // 展开为 int my_var = 1;#的作用是把参数“字符串化”，把传入的记号变成字符串字面量。注意它不会对参数内容做进一步宏展开。##的作用是把左右两边的记号拼接成一个新记号，常用于生成变量名、函数名。
这两个操作符特别能体现宏的“文本性”：普通函数只能处理运行时的数据，而宏可以处理代码的“形”——把代码变成字符串，或者把代码片段拼成标识符。这是宏至今没法被完全替代的原因之一。
3. 展开之后的代码怎么被吃掉：从预处理产物到机器码
3.1 一个完整示例的展开全貌
回到开头那个包含stdio.h的示例。预处理之后，stdio.h的全部内容会被完整插入源文件，宏THREE被替换成3，#include和#define这两行消失。核心代码变成：
int main(void) { int x = 3 * 3; printf("%d\n", x); return 0; }从这一小段就能看出两个关键结论。第一，宏替换发生在语法分析之前，所以替换后的代码必须本身就是合法的 C 代码。如果你定义了一个语法残缺的宏，错误要到展开之后、编译阶段才会报出来，报错位置往往还指向展开后的代码，排查起来很痛苦。
第二，宏展开会产生“代码副本”。每出现一次THREE，就被替换一次。如果一处代码里写了 100 个THREE，编译时就会生成 100 份字面量3。宏没有“唯一实体”的概念，它只有在每个使用点上的“复印件”。
3.2 编译器怎么处理展开后的表达式
从int x = 3 * 3;开始，编译器进入真正的编译阶段。它会对表达式做常量折叠：既然3和3都是编译期常量，3 * 3在编译阶段就能算出9，运行时不需要执行乘法指令。优化级别开高之后，编译器甚至可能直接把这个变量优化掉，凡是用到x的地方都替换成常量9。
这里要特别强调：#define本身不会产生任何“运行时代码”。宏在运行时的角色是“不存在”。你最终运行的程序，是编译器和汇编器从展开后的代码生成出来的机器码。宏名、宏定义都已经在那个世界完全消失了。
调试器里看不到宏的值，原因也在这里。符号表里根本没有宏的条目，它只活过一瞬间——在预处理阶段，在编译器正式工作之前。
3.3 展开和普通函数调用的本质差异
函数调用有明确的调用点，变量有明确的内存位置，但宏展开出来的代码没有自己的“地址”。它只是把自己粘贴到每一个出现的位置。这个差异带来几个实际后果：
- 你没法对宏取地址，
&SQUARE这个东西根本不存在。 - 宏不会带来任何函数调用开销，因为根本没有调用，也就没有压栈、跳转、返回。
- 宏产生的代码量和出现次数成正比。如果宏体很大又用了很多次，会显著增加代码体积。
所以就“性能”而言，宏本质上是“用空间换时间”的原始手段。没有调用开销，但代价是代码膨胀，以及文本替换层面的各种坑。用一张表对比会更直观：
| 对比项 | #define宏 | 内联函数 | const变量 |
|---|---|---|---|
| 类型检查 | 无 | 有 | 有 |
| 调用开销 | 无 | 通常无 | 无 |
| 存在时机 | 预处理阶段后消失 | 编译期存在 | 运行期存在 |
| 可调试性 | 差 | 好 | 好 |
| 作用域控制 | 差，只有#undef能终止 | 好 | 好 |
4. 宏最容易翻车的几个现场：括号、副作用与重复求值
4.1 缺括号是万恶之源
回到文章开头那个例子：
#define SQUARE(x) x*x int a = SQUARE(3 + 1);展开过程是这样的：
int a = 3 + 1*3 + 1;按照运算符优先级，先算乘法，结果是3 + 3 + 1 = 7，而不是16。原因就在于“参数替换”是原样替换，预处理不会自动给参数加括号，更不会自动给整个表达式加括号。它就像一个很笨的复制粘贴工具：你给它什么，它就贴什么。
正确的写法是：
#define SQUARE(x) ((x) * (x))这样SQUARE(3 + 1)展开为((3 + 1) * (3 + 1))，结果才是 16。为什么里外都要括号？外层括号保证整个表达式作为一个整体参与到更大的表达式里，内层括号保证参数内部的运算优先级不被破坏。类似的翻车还有：
#define DOUBLE(x) x + x int b = DOUBLE(2) * 3; // 展开为 2 + 2 * 3 = 8，而不是 12这类问题在功能宏里极其常见。我的经验是：写带参数的宏时，参数出现几次就套几层括号，最后整体再套一层，宁可多写也不能少写。
4.2 副作用问题：参数被“复制”而不是“求值一次”
再看一个更隐蔽的坑：
int i = 1; int c = SQUARE(i++);展开后是：
int c = ((i++) * (i++));这里有两个问题。第一，i++被执行了两次，变量被改了两次。第二，对同一个变量在同一个表达式中多次修改，在 C/C++ 标准里属于未定义行为，编译器怎么处理都有可能，结果完全不可预期。
这个 bug 特别坑人，因为单步调试时很难往“宏展开”方向想。函数不会有这个问题——函数调用时参数只求值一次，然后把值传给函数体。宏做不到，它本质是把参数的“文本”复制到多个位置，复制几次就求值几次。
所以，任何带副作用的表达式（比如i++、函数调用返回值）都不要传给功能宏，除非你明确知道宏体里每个参数只出现一次。
4.3 多语句宏与do-while(0)包装
如果宏体包含多个语句，坑就更大了：
#define INIT(a) a = 0; a = 1; if (flag) INIT(x); else something();展开后变成：
if (flag) x = 0; x = 1; else something();else直接变成悬空状态，编译报错。即便不报错，逻辑也完全乱了。经验做法是把多语句宏包在do { ... } while(0)里：
#define INIT(a) do { a = 0; a = 1; } while(0)这样宏整体是一条独立的语句，放进if、else分支都不会破坏语法结构。有人会问为什么不直接包一层大括号，因为大括号后面需要加分号，而if (flag) { ... };的写法会把整个if...else结构拆散，只有do-while(0)能完美收尾。
4.4 类型安全与调试体验的天然短板
宏没有参数类型检查。MAX(1, 2.5)这种调用，编译期通常不会有任何警告，但比较和返回都可能涉及隐式类型转换，埋下精度问题。反过来，在调试器里你没法观察“宏”的当前值，因为宏在编译前就没了。这些短板是宏被现代语言特性“嫌弃”的主要原因，也是你选择用宏之前必须想清楚的代价。
5. 把幕后搬到台前：用预处理输出查看真实替换过程
5.1 一条命令看到预处理全貌
面对“宏行为不符合预期”的困惑，最有效的做法不是猜，而是把预处理结果打印出来看。主流编译器基本都支持只做预处理的参数：
gcc -E example.c -o example.i-E表示只做预处理，结果写到example.i文件。打开这个文件，你能看到头文件内容被完整插入，所有宏都被替换完毕。文件里会有大量# 行号形式的行标记，那是给后续编译器定位源文件位置用的调试信息，直接忽略就行。
如果想看更干净的输出，可以加-P参数，去掉行标记。命令变成：
gcc -E -P example.c -o example.pure.c5.2 只想查某个宏定义时可以用另一招
引入标准头文件之后，example.i可能非常大，动辄几万行。如果只是想确认某个宏当前的展开值，可以换一种方式：
clang -E -dM example.c-dM会输出文件里所有生效的宏定义，适合排查“宏被其他头文件重新定义”的诡异问题。比如你明明定义了#define MAX 100，结果预处理后却变成了别的值，用这条命令一眼就能看出是谁干的。
5.3 一次完整的排查演示
假设你复制了我的错误示例：
#define SQUARE(x) x*x int square(int n) { return n * n; } int main(void) { int a = square(3 + 1); int b = SQUARE(3 + 1); return a + b; }执行预处理后，核心部分会是这样的：
int square(int n) { return n * n; } int main(void) { int a = square(3 + 1); int b = 3 + 1*3 + 1; return a + b; }看到这行，所有疑问都瞬间明朗了：函数参数是在运行前求值一次，所以a是 16；宏参数是文本复制，所以b是 7。与其死记“宏要加括号”的教条，不如亲手跑一遍这个过程。这个习惯一旦养成，宏相关的问题几乎都能一眼定位。
我给初学者的建议是：遇到任何宏相关的不符合预期的结果，第一反应永远是打开预处理输出看一眼，而不是盯着源码苦想。看一次展开结果，胜过翻十篇宏讲解文章。
6. 现在的 C/C++ 里，宏到底该用在哪
6.1 能用语言特性解决的问题，就别用宏
早期 C 语言没有const，很多常量只能靠宏定义。但现在的 C 和 C++ 早已不是这样。
整型常量可以这样写：
const int MAX_USERS = 100; enum { MAX_LEVEL = 10 };const变量有类型、有作用域，调试器里看得到名字；枚举常量还能被编译器参与更严格的类型检查。宏在这些方面全是短板，没有理由非要选它。
函数层面更是如此。C++ 里有内联函数和模板，C 语言里也有static inline函数。内联函数有类型检查、有作用域、参数只求值一次，绝大多数功能宏的活它们都能干，而且干得更好。宏唯一还能理直气壮站住的场景，是那些需要“操作代码文本本身”的地方。
6.2 宏依然不可替代的几块地盘
尽管宏问题很多，但它依然活着，而且会一直活着。下面这些场景里，宏确实比任何语言特性都合适。
头文件保护：
#ifndef MY_HEADER_H #define MY_HEADER_H /* 头文件内容 */ #endif条件编译，比如按调试配置启用不同代码：
#ifdef DEBUG printf("debug info\n"); #endif日志和断言类宏，因为它们需要自动带上__FILE__、__LINE__这些调用位置信息：
#define LOG_INFO(fmt, ...) \ do { \ printf("[INFO] %s:%d " fmt "\n", __FILE__, __LINE__, ##__VA_ARGS__); \ } while(0)需要把标识符拼接到代码里的场景，比如批量生成结构体成员或者函数名，##操作符在这里无可替代。这些场景的共同特点是：它们要求代码在编译前被“改写”，而不仅仅是运行时被“执行”。
6.3 真的要用宏时，守住这几条底线
如果你经过权衡，确定这里必须用宏，那么请遵守一套保守的写作规范。
第一条，宏名全大写，最好带项目前缀。宏没有作用域，定义之后到文件结束的所有代码都会受影响，一个普通变量名很容易和宏名撞车。
第二条，所有参数都要加括号，整个表达式也要加括号。宁可多套两层，也不要省。
第三条，多语句宏必须用do { ... } while(0)包裹，保证它在任何语法位置都能安全展开。
第四条，宏定义旁写清楚“展开后的效果”。我见过太多团队代码里一个宏用了几十处，谁都不敢改，因为没人知道它展开后到底长什么样。注释里写一行展开示例，后来的人会感谢你。
6.4 别忘了一个最实用的工具习惯
最后说个实用习惯：在工程里排查宏问题时，把预处理输出当成日常调试工具。现在的编译器都支持只做预处理，IDE 里也常常有“预处理文件”或类似的导出功能。把宏展开的过程变成“可见的东西”，你才能真正掌握#define，而不是靠猜。
我在宏上面栽过的跟头不算少，最深的体会是：不是宏不能碰，而是要把它严格限制在“代码生成”这个场景里。如果一件事用普通函数、const、模板能表达清楚，就别引入宏；如果必须用宏，就把该加的括号都加上，该包的do-while(0)包上，然后写清楚展开后的样子。养成“怀疑宏就先看展开结果”的习惯之后，你会发现#define其实没那么可怕，它只是一个工作地点在编译前的、说话特别直白的工具而已。
