clang -E source.c 直接输出预处理后代码，完成头文件展开、宏替换和条件编译裁剪，生成编译器实际输入的纯文本（.i文件），是验证宏行为最轻量高效的方式。
用 clang -E 直接输出预处理后代码
直接运行 clang -E source.c 就能在终端打印出宏展开、头文件内联、条件编译裁剪后的完整文本。它不生成目标文件，只做预处理——这是验证宏是否按预期展开最轻量的方式。
注意：输出里会混杂大量 #line 指令和内置宏定义（比如 # 1 "source.c"），这些是预处理器标记源码位置用的，不是你写的代码，可忽略或用 grep -v "^# " 过滤。
- 如果源文件用了
#include <stdio.h></stdio.h>，你会看到整个stdio.h内容被展开进来（可能几千行） - 若想限制只看你自己写的部分，加
-I.确保本地头文件路径正确，避免因路径问题导致某些头文件没展开 -
-E不检查语法错误，所以即使代码有编译错误，只要预处理能过，照样输出结果
把预处理结果保存到文件再查看
终端刷屏太快看不清？用 -o 把结果写进文件：clang -E source.c -o source.i。生成的 source.i 是纯文本，可用 less source.i 或编辑器打开逐行查。
这个文件就是后续编译阶段真正的输入——也就是说，编译器真正“看见”的代码，就是它。
- 文件名后缀用
.i是约定俗成（i来自cpp-output），Clang 和 GCC 都认 - 别用
.c当后缀存预处理结果，否则再用clang source.c会重新走一遍预处理，白忙活 - 如果宏依赖命令行定义（如
-DDEBUG=1），记得一起带上：clang -E -DDEBUG=1 source.c -o debug.i
常见卡点：为什么 -E 输出里看不到宏展开？
大概率是宏根本没被触发——比如写了 #ifdef DEBUG 却没用 -DDEBUG 定义它，那整段代码就被预处理器删掉了，自然不会出现在输出里。
- 检查是否漏传
-D参数，或者拼写错误（-DDEBUG≠-D debug） - 确认宏定义在使用前已声明；
#define写在#include后面，而头文件里又用了该宏，就会失效 - 留意宏是否被嵌套在未满足的条件编译块中，例如
#if 0 ... #endif包裹的内容完全不会出现在.i文件里
对比 GCC 的 -E 行为是否一致？
基本一致。Clang 和 GCC 的 -E 都遵循 POSIX 预处理器规范，输出结构、#line 格式、宏展开逻辑完全兼容。唯一细微差别是 Clang 默认启用更多内置宏（如 __clang__），而 GCC 输出 __GNUC__。
这意味着：你在 GCC 下验证过的宏逻辑，换 Clang 加 -E 看，结果应该一模一样——除非你显式依赖了某个编译器特有的宏。
- 跨工具链协作时，别写
#ifdef __clang__或#ifdef __GNUC__做功能开关，容易导致-E结果不可复现 - 若项目同时支持两者，建议用更通用的特征检测，比如
__has_include(<xx.h>)</xx.h>（Clang 支持，GCC 5.0+ 也支持）
预处理看似只是“替换文本”，但宏的展开顺序、作用域、条件裁剪逻辑全藏在 .i 文件里。很多人跳过这步，直接编译报错才回头查，其实绝大多数宏相关问题——比如参数求值两次、括号缺失、嵌套失效——一眼就能在 -E 输出里定位。
