宏定义由预处理器处理，发生在词法分析之后、语法分析之前，是编译流程中最早且独立的一环；它仅进行纯文本替换，不感知类型与作用域，展开后即从编译器视野中彻底消失。
宏定义由 C++ 预处理器（cpp）处理，不是编译器前端（如 clang -cc1 或 gcc 的 parser）负责的。 它发生在词法分析之后、语法分析之前，属于编译流程中独立且最早的一环。
预处理器在编译流程中的确切位置
标准 C++ 编译流程分四步：预处理 → 词法分析 → 语法分析 → 语义分析与代码生成。但实际顺序是：
- 源文件先被
cpp（或集成在clang/g++中的预处理模块）读入，执行所有#define、#include、#ifdef等指令 - 输出的是一个“已展开”的纯文本流，不再含任何宏或预处理指令
- 这个输出才交给真正的编译器（如
clang -cc1）做 tokenization 和 parsing - 所以
sizeof(FOO)中的FOO如果是宏，在语法分析阶段早已被替换成字面量或标识符——编译器根本“看不见”原始宏名
为什么不能用宏模拟模板或类型推导
因为宏是纯文本替换，不感知类型、作用域、表达式结构：
-
#define SQUARE(x) x * x在SQUARE(a + b)中展开为a + b * a + b，优先级错误 -
decltype(FOO)中若FOO是宏，decltype实际作用的是宏展开后的表达式，不是宏本身 - 宏无法重载、无法参与 SFINAE、不能捕获局部作用域变量（比如
__LINE__是常量，不是变量） - 调试器看不到宏——它们在进入编译器前就消失了；GDB 中
print FOO会报No symbol "FOO"
如何验证宏是否已被预处理器处理
用编译器自带的预处理选项直接查看中间结果：
立即学习“C++免费学习笔记（深入）”；
- GCC/Clang：
g++ -E main.cpp或clang++ -E main.cpp，输出就是预处理后的代码 - MSVC：
cl /EP main.cpp（注意大小写），/P还会生成main.i文件 - 关键观察点：所有
#include变成大段头文件内容；#define消失；printf("val=%d", VAL);若VAL是宏，此处已变成具体数字或字符串字面量 - 如果看到
#line 42 "main.cpp"行，说明预处理器还在维护源码映射，方便报错定位——但这和宏无关，是预处理器的调试支持机制
宏的边界很清晰：它只活在预处理这一步里。一旦过了 -E 阶段，它就彻底不存在了。很多人试图在模板特化或 constexpr 上“绕过类型系统用宏”，本质上是在和一个早已下班的工具较劲。
