gcc -E用于仅执行预处理，即宏展开、头文件插入和条件编译裁剪，输出纯C/C++文本（含行号标记），默认输出到stdout，常用于调试宏定义、验证#include和#ifdef逻辑。
什么时候该用 gcc -E
当你需要看预处理后的代码，而不是编译或链接结果时，gcc -E 才真正有用。它不生成目标文件，也不检查语法错误，只做宏展开、头文件插入、条件编译裁剪这三件事。
典型场景包括：调试宏定义冲突、确认 #include 实际引入了哪些内容、排查 #ifdef 逻辑是否按预期生效、或者验证自定义的 #define 是否被正确展开。
gcc -E 输出的是什么格式
输出是纯 C（或 C++）文本，但带大量行号标记（# line "xxx"），可读性差，不适合直接编辑。它不是“美化后”的源码，而是编译器内部预处理阶段的原始输出。
- 默认输出到 stdout，建议重定向：
gcc -E main.c > main.i - 加
-P可去掉行号标记，但会丢失位置信息，调试时慎用 - 加
-dM能列出所有宏定义（含系统宏），适合查__linux__或__x86_64__是否存在 - 不支持
-o指定输出文件名（除非配合-x c等显式语言标识）
常见误用和坑
很多人以为 gcc -E 能帮查语法错误，其实不能——预处理器不管语法，int x;; 和 #define FOO bar(baz) 即使有错也会原样输出。
- 头文件路径没配对？
gcc -E会报fatal error: xxx.h: No such file or directory，这时得检查-I或CPATH - 宏嵌套太深？GCC 默认限制 200 层，超限会停在某一层并报
macro is not defined，实际是展开中断，不是未定义 - 用了
__FILE__或__LINE__？它们在-E输出里已替换成字面值，别指望看到原始字符串 - C++ 头文件用
gcc -E处理可能出乱码——应改用g++ -E，否则std::相关宏可能不生效
和 cpp 命令什么关系
gcc -E 底层调的就是系统预处理器（通常是 cpp），但行为更可控：它自动带入 GCC 自身的系统头路径和内置宏，而裸跑 cpp main.c 很可能找不到 stdio.h。
- 想复现 GCC 的预处理环境？必须用
gcc -E，不要直接调cpp - 想跳过 GCC 内置宏？加
-no-integrated-cpp（已废弃）或改用cpp -nostdinc，但代价是失去标准库支持 -
gcc -E -v会打印出完整的预处理命令行，包括所有隐式-I和-D，这是查构建环境最直接的方式
预处理本身不耗资源，但输出体积可能远超源码——一个 #include 在 C++ 里能膨胀到数万行，别直接 cat，先 head -50 或管道进 less。
