为什么 C++ 引入 import（C++20 Modules）特性

C++ 在 C++20 中引入了模块（Modules），通过 import 关键字替代传统的 #include 头文件机制的部分用途。其核心动机是解决 C/C++ 头文件模型长期存在的工程痛点，并显著提升编译速度、可维护性与可用性。

背景：传统 `#include` 的问题

文本拼接模型的固有缺陷
#include 只是预处理期的文本复制粘贴：
- 重复解析同一份头文件（即便有 include guard 也只是避免重复定义，解析仍会发生）。
- 容易引入宏污染（宏全局可见，互相干扰，难以约束可见性）。
- 依赖顺序敏感（宏/类型前置声明的顺序问题）。
编译速度与可扩展性差
大型工程动辄数千头文件，编译器反复解析同样的声明，导致：
- 冷启动全量编译慢。
- 增量编译常常因为依赖扇出大而不够快。
ODR（One Definition Rule）风险与可见性混乱
模板/内联函数在多个翻译单元重复实例化与定义，容易触发 ODR 问题。
封装性和接口表达能力不足
头文件暴露过多实现细节；没有“接口/实现”物理级隔离的语言级语义。

真正的语言级模块化与清晰的边界
- 使用 module;、export module 定义模块，export 对外暴露接口，内部实现默认不可见。
- 通过 import <module-name>; 引用时，仅载入已导出的符号，避免实现细节泄漏。
显著提升编译速度
- 编译器可将模块接口编译为“已编译模块接口”（BMI/CMI），类似二进制接口缓存。
- 下游编译单元 import 模块时，跳过重复解析文本头文件的开销。
- 大型项目可获得数量级的冷/热编译加速（视工具链与组织方式而定）。
更好的封装与可维护性
- 默认不导出即不暴露，可控的符号可见性，减少命名污染与耦合。
- 宏不会跨模块传播，降低“宏地狱”风险。
更可靠的一致性与 ODR 安全
- 模块接口是编译器验证过的单一事实来源（single source of truth）。
- 模板导出接口在模块边界内更易于保证一致性。
工具链与增量构建友好
- 构建系统可基于模块依赖图做更精确的最小重建；IDE 可更快地做语义索引。

共存与渐进迁移
- 现有头文件可通过“头文件单元”（header units）机制用 import "header.hpp"; 方式引入，作为过渡。
- 新代码优先以模块接口单元（.ixx/.mpp 等）导出 API。
- 实现细节放入模块实现单元，仅在同模块内使用 import。
宏与条件编译的处置
- 宏不再跨模块传播；如需常量，优先使用 constexpr 或枚举。
- 必须导入前就确定的编译条件，可通过配置或构建系统解决。
与预编译头（PCH）的对比
- PCH 是编译器私有的全局大缓存，脆弱且跨工具链不可移植。
- Modules 是语言级机制，粒度细、可组合、可移植，依赖关系可被构建系统理解。

// math.hpp
#pragma once
inline int add(int a, int b) { return a + b; }

// main.cpp
#include "math.hpp"
int main() { return add(1, 2); }

1
2
3

// math.ixx (模块接口单元)
export module math;
export inline int add(int a, int b) { return a + b; }

1
2
3

// main.cpp
import math;
int main() { return add(1, 2); }

Q: 所有编译器都支持了吗？
- GCC、Clang、MSVC 已支持 C++20 Modules，但细节（如 BMI/CMI 文件扩展名、搜索路径）与构建系统集成仍需配置。使用 CMake 3.28+ 可获得更好支持。
Q: 头文件还能用吗？
- 可以，共存。建议新公共 API 采用模块，旧代码逐步过渡为头文件单元或真正的模块。
Q: 会不会破坏模板库生态？
- 反而更好：模板可在模块边界导出，显著减少重复实例化带来的开销与 ODR 问题。
Q: 性能提升有多大？
- 视工程规模与模块化程度而定，中大型项目常见 2×–10× 的冷/热编译加速。需合理拆分模块与缓存策略。