gcc -e 用于查看宏展开结果，需重定向到文件（如 gcc -e source.c > expanded.i）以便审查，配合 -d、-u 可模拟不同编译条件，-e 输出是验证宏行为的唯一权威依据。
用 gcc -E 看宏展开，但输出默认是标准输出，容易刷屏
直接运行 gcc -E source.c 会把整个预处理结果（包括所有头文件展开）打到终端，几百上千行一闪而过，根本没法查你关心的那个宏。实际调试时必须重定向到文件。
- 推荐写法：
gcc -E -I./include source.c > expanded.c（加-I确保能找到自定义头文件） - 如果只想看某一段，可用
grep过滤：gcc -E source.c | grep -A5 -B5 "MY_MACRO" - 注意：
.i是传统后缀，但扩展名不影响内容，用.c或.txt更方便用编辑器打开
-D 定义宏后再展开，模拟不同编译条件
很多宏依赖 #ifdef 或 #define DEBUG 控制逻辑，不主动定义就看不到分支代码。比如想验证日志宏是否生效，得手动注入定义。
- 启用条件编译：
gcc -E -DDEBUG=1 -DENABLE_LOG source.c > debug.i - 取消某个宏定义（用于对比）：
gcc -E -UDEBUG source.c > no_debug.i - 多个定义可连写：
-DFOO=1 -DBAR=2，不用空格分隔
可变参数宏的逗号问题，-E 输出里一眼就能发现
当宏调用没传可变参数时，GCC 展开后会多出一个孤立逗号，比如 vprintf("msg",); —— 这种语法错误在 -E 输出里非常显眼，比编译报错定位更快。
- 典型错误宏：
#define LOG(fmt, ...) printf(fmt, __VA_ARGS__) - 调用
LOG("hello");后，gcc -E输出中会出现printf("hello",); - 修复后宏应为：
#define LOG(fmt, ...) printf(fmt, ##__VA_ARGS__)，此时-E输出里逗号消失
配合 -g3 在 GDB 里查宏，不是所有宏都能“看见”
gcc -g3 确实能让 GDB 识别宏定义，但前提是宏在源码中是显式定义的（即写在 .c 或 .h 里），而不是仅通过 -D 命令行注入的。后者只影响预处理，不进调试符号表。
- 能查的：
info macro MY_MACRO（在 GDB 中）——仅对源码里#define的宏有效 - 查不到的：用
-DMY_MACRO=42注入的宏，GDB 不知道它存在 - 真正要确认行为，还是得靠
-E看实际展开结果，这是唯一权威依据
#if 和 ## 拼接，最终都得落到 -E 输出里去核对——任何“我以为它该这样”都不算数，只有展开后的代码说了算。
