模块是编译模型重构而非头文件语法糖，它跳过预处理、生成二进制接口单元（BMI），不导出宏、不重复解析，需编译器标志和构建流程支持，目前MSVC支持最稳。
模块不是头文件的语法糖，而是编译模型的重构
模块不是“带 import 的头文件”，它彻底绕开了预处理阶段。传统头文件靠 #include 复制文本、宏展开、重复解析，而模块把接口声明（export module）和实现（module）编译成二进制接口单元（BMI），被导入时直接加载符号信息，不重跑预处理器、不重复编译模板、不污染全局宏。
这意味着：头文件里写 #define DEBUG 1，所有 #include 它的 TU 都受感染；模块里定义的宏根本不会导出，import 后也看不见。
怎么写一个最简可用的 C++20 模块
模块分两部分：接口单元（必须 export module）和实现单元（可选，用 module 声明）。不能混在同一个文件里用 export module 和 module。
- 接口文件
math.mpp（后缀无强制要求，但别用.h或.hpp，避免被旧构建系统误当头文件）：export module math; export int add(int a, int b) { return a + b; } - 实现文件
math_impl.cpp（可选，用于分离声明与定义）：module math; int multiply(int a, int b) { return a * b; } - 使用方
main.cpp：import math; int main() { return add(2, 3); }
关键点：import 语句必须出现在任何声明之前（包括 #include），且不能出现在头文件里——模块不能被头文件包含。
立即学习“C++免费学习笔记（深入）”；
Clang/GCC/MSVC 对模块的支持现状很现实
不是“开了 -std=c++20 就能用”，模块需要额外编译器标志和构建流程配合：
- Clang 17+：需
-fmodules-ts（已过时）或-fmodules+-x c++-system-header等组合，BMI 输出路径需手动管理，import查找依赖modulemap或显式-fmodule-file= - GCC 11+：实验性支持，用
-fmodules-ts，但不生成标准 BMI，而是内部表示；不支持跨 TUs 导入模板定义，实际项目中容易卡在“找不到符号” - MSVC 19.28+（VS 2019 16.9+）：目前最稳，用
/experimental:module，自动处理 BMI 生成与查找，但要求所有模块源文件统一用.ixx后缀（接口）和.cppm（实现），且不能和传统头文件混用同一构建目标
错误现象常见：error: expected unqualified-id before 'import' —— 编译器根本没启用模块支持；fatal error C1114: cannot import module 'math' —— MSVC 下忘了加 /experimental:module 或路径没对上。
模块不能解决所有头文件问题，尤其别指望它自动处理宏和条件编译
模块导出的是声明和定义，不是文本。这意味着：
-
export不会导出#define，import后无法访问模块内定义的宏 -
#ifdef在模块接口单元里仍有效，但它只作用于该 TU 编译过程，不影响其他import者 - 传统库（如 Boost、Eigen）短期内不可能改模块，你得继续
#include它们；混合模式下，#include必须放在import之前，否则 Clang/MSVC 会报错 - 模板隐式实例化仍发生在使用点，模块只是让声明更干净——但如果你在模块里写了
export template，用户struct Vec { T data; }; import后仍需看到完整定义才能实例化，所以接口单元常要内联实现
真正卡住落地的，从来不是语法，而是构建系统能否可靠生成、缓存、复用 BMI，以及团队是否接受“一个模块 = 一组固定命名、固定依赖、不可被宏劫持”的契约。这点比学会写 export module 难得多。
