模块是编译模型重构而非头文件替代，绕过文本包含与预处理，通过二进制接口（bmi）统一导出/导入声明，要求编译器支持（如clang 13+/msvc 19.29+/gcc 11+），且需严格遵循语法与构建规则。
模块不是头文件的替代品，而是编译模型的重构
模块（Modules）不是让 #include 换个写法就能用的东西。它把“文本包含 + 预处理 + 多次编译同一份声明”这套老机制整个绕过去了——声明不再靠复制粘贴进每个 TU（translation unit），而是由编译器统一导出、导入二进制接口（BMI）。这意味着：import 不展开宏、不污染全局命名空间、不重复解析模板声明。
常见错误现象：import std; 报错 “module not found”，或 import "foo.h"; 被误认为合法（实际 C++20 不允许 import 传统头文件，除非用 import <vector>;</vector> 这类头单元，且需编译器支持）。
- 必须用支持模块的编译器：Clang 13+（需
-std=c++20 -fmodules）、MSVC 19.29+（/std:c++20 /experimental:module）、GCC 11+（实验性，-std=c++20 -fmodules-ts，但实现不完整） - 模块接口单元（
.ixx或.cppm）不能含#include，也不能有未导出的定义；否则编译器会拒绝生成 BMI - 模块分区（
module :private;）容易被当成命名空间用，其实它只控制符号可见性，不隔离 ODR 违规
怎么写一个最小可用模块（以 Clang 为例）
别从 std 开始试——先写自己的模块，避开标准库支持差异这个坑。目标是让一个 main.cpp 通过 import 使用你写的函数，且不依赖 #include。
示例结构：
立即学习“C++免费学习笔记（深入）”；
math.ixx
export module math;
export int add(int a, int b) { return a + b; }main.cpp：
import math;
#include <iostream>
int main() { std::cout << add(2, 3); }关键点：
- 模块名（
math）必须全局唯一；重名会导致 BMI 冲突，编译器通常不报错但行为未定义 -
export module math;必须是文件第一行非空非注释行；前面哪怕一个空行，Clang 就报 “expected module declaration” - Clang 编译命令分两步：
clang++ -std=c++20 -fmodules -x c++-system-header vector（预编译标准头单元），再clang++ -std=c++20 -fmodules main.cpp math.ixx - MSVC 要求显式指定模块输出路径：
/module:interface /module:output math.ifc，否则找不到接口文件
为什么 import <vector></vector> 在某些项目里还是失败
这不是你代码的问题，是工具链没对齐。标准头单元（header units）依赖编译器预编译一套可信的 .pcm（Clang）或 .ifc（MSVC）文件，而这些文件必须和当前编译参数（如 _LIBCPP_VERSION、_GLIBCXX_DEBUG）完全一致。
典型症状：import <vector></vector> 编译通过，但链接时报 undefined reference to 'std::vector<int>::~vector()'</int> ——说明模块导入的声明和链接时的库 ABI 不匹配。
- Clang 下必须用
-stdlib=libc++配合import <vector></vector>，换libstdc++就不行（GCC 的头单元支持更弱） - MSVC 的
import <vector></vector>要求项目设置 “C++ Language Standard” 为 “ISO C++20 Standard”，且禁用 “Conformance mode” 以外的扩展选项 - 跨构建目录共享 BMI 文件？别试。BMI 包含绝对路径和编译器内部哈希，移动后直接失效
模块和模板一起用时最危险的陷阱
模块能导出模板声明，但不能导出未实例化的模板定义——这点和头文件完全不同。如果你在模块接口里写了 export template<typename t> struct X { T val; };</typename>，没问题；但若写了 export template<typename t> void foo() { /* 实现 */ }</typename>，Clang 会警告 “exported function template definition may not be instantiated outside module”，而 MSVC 可能静默失败。
真正要命的是特化：
- 在模块内显式特化
std::hash<mytype></mytype>？不行。标准禁止用户向std添加特化，模块里做这事不会报错，但链接时可能崩溃 - 跨模块特化自己的模板？必须在主模块接口中声明特化，且特化定义也得在同一个模块单元里，否则 ODR 违规
- 想导出概念（
export concept C = ...;）？可以，但 GCC 12 之前不支持，Clang 14 才稳定
模块不是银弹。它解决的是头文件带来的编译膨胀和命名污染，但没法绕过 ODR、ABI 兼容、模板实例化时机这些底层约束。越早意识到模块是编译期契约而非语法糖，越不容易掉进“写了 import 就万事大吉”的坑里。
