3.2 宏系统

3.2 宏系统

本节摘要：宏是在编译（或加载）阶段把"宏调用"改写为"新代码"的机制，是"编译期 × 干预"坐标的旗舰技术。本节厘清文本宏与语法宏的本质分野，拆解卫生性这一经典难题，并用 Rust 声明宏完成一次完整演练：从模式定义到展开结果，再到排错思路。

两种展开时机的分野

宏的定义只有一句话：你写一段"描述代码该怎么生成"的声明，编译器在合适的时机按声明展开出新代码。但"合适的时机"有两种，它们的可靠性天差地别。

文本宏工作在语法分析之前：预处理器拿着字符流做替换，根本不知道什么是语法。1.2 节里 SQUARE(3+1) 算出 7 的翻车就发生在这个世界。语法宏工作在语法分析之后：输入是被解析过的语法树片段，输出也是语法树片段，展开产物还要通过完整的类型检查。两代技术的分水岭就一句话——宏操作的是字符还是结构。

图：文本宏与语法宏的两级流水线

一、卫生性：语法宏的头号难题

语法宏解决了"结构"问题，立刻面对第二个问题：宏里写的名字，到底指谁。

考虑一个伪代码场景：宏 swap(x, y) 展开后需要一个临时变量 tmp。如果使用者的作用域里恰好也有 tmp，宏展开引入的名字会不会覆盖它？反过来，宏展开处引用的一个普通名字，会不会意外解析到使用者作用域里的同名变量？这两个方向的意外都叫变量捕获，解决它的性质叫卫生性（hygiene）。

卫生宏系统给每个语法片段标记来源——宏定义引入的名字永远指回宏定义的世界，使用处传入的名字永远属于使用者的世界，两个世界互不串门。Rust 与现代 Scheme 都内置了这一性质；不卫生的系统（如早期 C 宏）则要求宏作者手动用罕见前缀躲避，纯属碰运气。理解卫生性，你就理解了为什么"宏能不能安全引入辅助变量"在不同语言里答案截然相反。

二、演练：用 Rust 声明宏消灭样板

背景：一个配置模块要支持多种类型的取值方法——get_int、get_str、get_bool，各自逻辑几乎一样，只有类型与默认值不同。手写三份是典型样板。

操作：声明宏用"模式 → 展开模板"描述这种重复。

macro_rules! getter {
    // 模式：宏名、内部类型、默认值三个"洞"
    ($name:ident, $ty:ty, $default:expr) => {
        pub fn $name(&self, key: &str) -> $ty {
            match self.inner.get(key) {
                Some(v) => v.parse::<$ty>().unwrap_or($default),
                None => $default,
            }
        }
    };
}

impl Config {
    getter!(get_int, i64, 0);        // 展开出完整的 get_int 函数
    getter!(get_str, String, String::new());
    getter!(get_bool, bool, false);
}
​

结果：三段重复函数体收敛为三行声明。展开发生在编译期，产出的函数与手写完全等价，调用方在 IDE 里能看到它们。解读：$name:ident 这类标注叫片段说明符——宏按类别（标识符、类型、表达式）匹配输入，而不是按字符匹配，这是声明宏"结构化"的最低限度体现。变式：若要支持带文档注释或可见性修饰的变体，加一条模式分支即可；模式匹配不上时，编译器会明确指出哪个调用点不匹配任何分支——比文本宏时代"报错在展开后的天书里"进步了整整一代。

声明宏的边界也在这场演练里显形：它只能按模式"填洞"，做不了需要语义判断的事——比如"遍历结构体的每个字段生成代码"。那个层级的任务要交给过程宏：宏本身是一个独立的编译单元，拿到的是完整语法树，用普通代码遍历、改写、再交还编译器。过程宏的实操放在 4.2 静态语言一节，那里有真实结构体的字段级展开。

三、宏使用的红线

宏的表达力越强，越需要纪律。三条红线来自无数项目的教训：其一，宏是最后手段——能用手写函数、泛型、继承解决的重复，不值得引入宏的心智成本；其二，宏产物必须可推演——调用处读宏名要能猜出八成行为，做不到就该换 API；其三，宏内部不偷 magic——隐藏的全局状态、隐式副作用、对调用环境的隐式假设，都会让展开结果无法预测。判断一个宏是否合格，标准很简单：让新人读宏的调用处，他能否在不看宏定义的情况下正确使用它。

延伸辨析：文本宏今天还剩哪些正当岗位

把文本宏说得一文不名并不公平——它只是不该再承担"语言内代码生成"的重任，但在语言之外的场合仍有正当岗位。构建脚手架里的模板替换（把项目名、版本号填进工程模板）、资源文件的条件编译开关、文档版本号注入，共同特征是：操作对象是配置文本而非程序语义，替换错了顶多构建失败，不会悄悄改变程序行为。判断一条边界因此可以简化：替换结果要不要参与类型检查？要，就必须用语法宏；不要，文本替换依然是低成本工具。

另一个常被问起的问题：为什么不能给 C 预处理器打补丁，让它"懂一点语法"？历史答案是"补不齐"——语法理解是全或无的命题：不理解作用域就无法解析名字，不理解类型就无法解析重载，逐点修补最终等于重写一个编译器前端。现代语言的路线因此一致：宏要么不进语言（构建期代码生成），要么以完整语法树进语言（语法宏），不存在中间档。

把这个结论带回工程判断：当你发现自己在用文本替换手段改程序语义时——无论是正则改代码还是脚本拼函数——都应该停下来问一句：这一步该不该交给语法宏或代码生成器？语义级生成交给结构化工具，文本级工具退守配置与文档，各归其位后，3.2 开头那张两级流水的对比图就不再是历史课，而是每天的工程边界感。

本节要点回顾

• 本质分野：宏操作字符还是语法树，决定了它是历史教训还是现代工具。
• 卫生性：宏引入的名字与使用者提供的名字互不干扰，是语法宏安全性的基石。
• 声明宏演练：模式加模板即可消灭类型级样板，片段说明符保证结构化匹配。
• 边界：声明宏只会填洞，字段级遍历与语义改写是过程宏（操作完整 AST）的领地。
• 三条红线：最后手段、产物可推演、内部无 magic。

宏在编译期改写代码，改写的对象是什么？是语法树。下一节把这块"通用货币"放到显微镜下，学会读它、数它、操纵它。