10. 预处理器

预处理器是翻译流程中最先执行的一层，它按指令对源码做文本级变换，然后把结果交给编译器。理解这一层，能解释很多“代码看起来没问题，但编译结果不符合预期”的现象。

1. 预处理器到底做什么

预处理器并不理解完整的 C 语义，它只处理以 # 开头的指令，核心动作是文件包含、宏替换和条件选择。换句话说，它先把“你写的多文件源码”整理成“编译器真正看到的翻译单元文本”，语法分析和类型检查发生在后续阶段，而不是这里。

2. 这章的阅读顺序

建议从 10.1 #define 与 10.2 #include 开始，先掌握最常见的替换与包含机制；再看 10.3 条件编译 与 10.4 诊断指令，理解如何按平台和配置裁剪代码；之后阅读 10.5 #embed、10.6 #pragma、10.7 #line，把高级扩展与可移植边界补齐。

3. 使用边界

预处理器的能力很强，但它是“文本替换强、语义感知弱”的工具。宏若替代类型系统和函数接口，调试难度会急剧上升；条件编译若缺少统一策略，代码路径会碎片化。稳妥写法通常是：把预处理器用于配置入口和少量跨平台桥接，把主要业务逻辑留在可被类型系统约束的 C 代码里。

4. 一致性组织建议

预处理条件最好集中在少量配置头中定义，再由业务代码读取统一宏。这样可以避免同一能力在不同源文件里出现不一致判断，减少“某些文件走了 A 路径、另一些文件走了 B 路径”的隐蔽问题。

5. 宏与函数的职责边界

宏适合做条件编译开关、常量记号拼接和极少量平台桥接，不适合承载复杂流程控制。只要逻辑已经需要类型检查、调试断点和清晰调用边界，就应优先改为函数或 static inline。把“文本替换”与“语义执行”分开，后续排错会容易得多。

6. 预处理问题的定位顺序

遇到可疑宏行为时，先看预处理输出，再看语义诊断，最后看链接结果。这个顺序与翻译阶段一致：先确认记号是否被展开成预期形式，再判断类型与控制流是否正确。很多看似“编译器怪异”的问题，本质都发生在预处理展开阶段。