宏污染在import中自动消失，因为import是语义导入而非文本替换：#include会原样粘贴头文件并传播宏定义，而import仅暴露export声明，预处理器指令（如#define）不跨模块传播。
宏污染为什么在 import 里自动消失
因为 import 不做文本替换，而是语义导入。传统 #include 把头文件内容原样“粘贴”进当前翻译单元，宏定义随之生效并污染后续所有代码；而模块导入时，编译器只暴露导出的声明（export 修饰的内容），预处理器指令（包括 #define）根本不会跨模块边界传播。
这意味着：即使你用 import "legacy.h" 导入一个含 #define min(a,b) ((a) 的旧头文件，这个 <code>min 宏也不会出现在你的源文件里 —— 它被严格限制在模块编译单元内部，对调用方完全不可见。
但 import "legacy.h" 本身不支持宏配置怎么办
这是最常踩的坑：老式头文件常依赖宏开关（比如 #ifdef ENABLE_LOGGING）来控制功能分支，而 import "legacy.h" 无法传递这些宏，导致编译失败或行为错乱。
- 不能在
import前加#define ENABLE_LOGGING—— 预处理发生在模块编译阶段之前，此时模块已编译为 BMI，宏无效 - 也不能在模块接口文件里
#define后再export—— 宏不是 C++ 实体，无法导出 - 正确做法是用包装头文件生成**专用模块变体**：
// legacy_with_logging.ixx export module legacy.logging; #define ENABLE_LOGGING #include "legacy.h"
// legacy_no_logging.ixx export module legacy.no_logging; #include "legacy.h"
然后在主代码中按需 import legacy.logging; 或 import legacy.no_logging;，每个变体对应一份独立 BMI，宏状态被固化在模块构建时。
哪些宏会意外“漏出来”？
极少数情况下，宏仍可能间接影响模块使用者，主要发生在以下场景：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 模块接口文件（.ixx）里直接写了
#define并导出了内联函数，而该函数体中用了宏 —— 此时宏展开发生在调用方翻译单元，等于“泄漏” - 模块导出的类中使用了宏定义的类型别名（如
#define HANDLE void*），且该别名未被封装 —— 调用方看到的是void*，但语义已失真 - 用
import <windows.h></windows.h>这类巨无霸系统头时，某些编译器（如 MSVC）会启用隐式模块模式，但仍可能把部分宏带入全局作用域 —— 这属于实现偏差，非标准行为
真正安全的做法是：模块接口只导出清晰命名的 C++ 实体（函数、类、概念），所有宏逻辑收进模块实现内部，绝不让宏参与接口契约。
和 #pragma once / include guard 不是一回事
有人误以为 #pragma once 或 #ifndef 能解决宏污染，其实它们只防重复包含，不隔离作用域。哪怕头文件用 #pragma once 包裹，只要被 #include 进来，里面的 #define PI 3.14 照样污染全局。
Modules 的隔离是编译模型级的：宏属于预处理层，模块属于语义层，二者天然正交。这也是为什么你无法用模块“导出宏”，也无需担心它“导入宏”——它根本不在同一个抽象维度上。
实际迁移时最容易忽略的一点：模块不拯救坏设计。如果旧头文件把几十个配置宏、工具宏、断言宏全堆在顶部，直接改 #include 为 import 只是掩盖问题；必须配合接口提炼，把真正需要暴露的 API 单独抽成 clean module，其余宏逻辑下沉或重写为 constexpr/constinit 替代。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
