为什么 #include 是构建瓶颈？
传统头文件包含机制会让每个 .cpp 文件重复解析同一份头文件（比如
Modules 把接口与实现分离成二进制模块单元，编译一次后生成模块接口单元（.pcm），后续导入只需读取该二进制快照，跳过词法/语法分析和宏处理。
如何导出一个可复用的模块接口？
模块接口单元（.ixx 或 .cppm）必须显式声明导出内容，不能靠“包含即导出”。未导出的实现细节（如辅助函数、私有类）不会污染导入者的编译环境，这是物理依赖解耦的关键。
-
export module math_utils;声明模块名，必须是文件首条非注释语句 - 仅
export修饰的声明才对外可见：export int add(int a, int b) { return a + b; } - 内部实现可写在
module;区块里（不导出）：module; namespace detail { constexpr int square(int x) { return x * x; } } - 可导出整个命名空间：
export namespace geometry { struct Point { int x, y; }; }
Clang / MSVC 模块构建流程差异
Clang 和 MSVC 对模块的构建链路设计不同，直接影响 CI 配置和增量编译行为：
立即学习“C++免费学习笔记（深入）”；
- Clang 要求先用
-x c++-system-header或--precompile预编译标准库模块（如std），再通过-fprebuilt-module-path引用；否则会回退到头文件模式 - MSVC 默认启用标准库模块支持（需 `/std:c++20 /experimental:module`），且模块接口编译命令为
cl /c /interface /exportHeader，生成.ifc文件 - 两者都不支持跨编译器模块二进制兼容——
clang-built .pcm不能被cl.exe导入 - 模块依赖必须显式声明：
import std.core;或import "my_math.ixx";，路径需在-fmodule-map-file（Clang）或 `/module:reference`（MSVC）中注册
哪些代码不适合立刻模块化？
不是所有头文件都能平滑迁移。以下情况会卡住或倒退：
- 含复杂宏逻辑的头文件（如 Boost.Preprocessor 或 Qt 的
MOC宏）——Modules 不解析宏，export macro尚未标准化 - 使用
#pragma once或#ifndef包裹但实际依赖文本包含顺序的头文件（如某些 C 风格 SDK）——Modules 消除了包含顺序语义 - 模板定义分散在多个头中、靠隐式实例化传播的代码——需确保所有模板声明在模块接口中完整导出，否则链接时报
undefined reference - 第三方库未提供模块接口（如大多数 vcpkg 包）——只能用
module : partition封装其头文件，但无法消除预处理开销
真正节省时间的模块化，始于对“谁依赖谁”的显式建模，而不是把 #include 换成 import 就完事。模块接口文件一旦变更，所有导入它的 TU 都要重编译——这点比头文件更严格，别低估接口稳定性成本。
