C++20 的 import：不是“更好用的 #include”，而是换了一套思维

上周帮同事调一个编译慢得离谱的模块，光预处理就占了 42 秒。他顺手 #include <vector> 和 <string> 各十几次，头文件层层嵌套，宏定义满天飞——最后发现，真正用到的其实就三行 std::string::substr()。那一刻我突然意识到：我们还在用 1983 年的设计逻辑，去写 2024 年的代码。

C++20 引入的 import，常被简单理解为“#include 的升级版”。这就像说电灯是蜡烛的升级版——技术上没错，但忽略了光的本质变了。

#include 是文本拼接。你写 #include <memory>，编译器就真的把那个头文件整个复制粘贴进你的源码里，不管你要不要 std::unique_ptr，也不管它内部又 #include 了多少层。结果就是：同一份声明，在一个 .cpp 文件里可能被展开、解析、检查语义几十次。而 import 不是复制文本，是导入已编译好的模块接口——类似 Python 的 import json，或 Rust 的 use std::collections::HashMap：一次编译，多次复用，且接口契约清晰、无副作用。

真正让 import 落地的，不是语法本身，而是模块接口单元（module interface unit）的写法。它长这样：

// math_utils.ixx
export module math_utils;

export int square(int x) { return x * x; }
export double distance(double x, double y) { return std::sqrt(x*x + y*y); }

注意两个关键词：export module 声明这是个模块；export 修饰的函数，才是对外可见的“出口”。没加 export 的辅助函数、静态变量、宏定义？统统不暴露——它们被关在模块的“门后”，不会污染全局命名空间，也不会触发意外的宏替换。

这点太关键了。以前写头文件，总得战战兢兢加 #pragma once 或 #ifndef MATH_UTILS_H，生怕别人多 #include 一次就炸；现在，import math_utils; 无论写多少遍，模块只初始化一次。重复导入不等于重复解析，更不等于重复实例化模板。你甚至可以在不同 .cpp 文件里 import 同一个模块，它们共享同一份类型信息——这意味着 std::vector<int> 在模块 A 和模块 B 中，是真正同一个类型，跨模块 dynamic_cast 或 std::is_same_v 都能正确工作。这在传统头文件模型里，靠宏和 extern template 挣扎多年都难彻底解决。

当然，现实没那么丝滑。目前主流编译器对模块的支持仍带“实验性”标签：MSVC 最成熟，GCC 13+ 和 Clang 17+ 可用但需显式开关（如 -fmodules-ts 或 -std=c++20 -fmodules），且模块二进制格式尚未标准化。这意味着你不能把 .pcm（precompiled module）文件直接发给同事，指望他 import 就跑——模块目前仍是编译时绑定的，不是链接时或运行时的分发单元。

所以务实的做法是：新项目起步，优先用 import 写内部模块；老项目迁移，不必强求“全盘替换”，但可以从最重、最乱、最常被 #include 的头文件入手。比如把一坨封装了网络、日志、配置的 common.h，拆成 net_client, logger, config_reader 三个小模块。每个模块只 export 真正需要的类和函数，删掉所有 #define DEBUG_LEVEL 3 这类全局宏——这些宏，该放 build config 里，不该在接口里飘。

还有一个易被忽略的细节：import 支持模块分区（module partitions）。大模块可以拆成逻辑块，主模块只 export import :detail;，把实现细节藏起来。这比头文件里写 // internal use only 的注释靠谱多了——编译器真会拦住越界调用。

最后说句实在话：别指望 import 让编译速度“立竿见影”。如果你的模块接口里 import <boost/hana.hpp>，那还是慢。模块加速的前提，是你愿意为接口做减法：少导类型、少导模板、少依赖重型第三方。真正的收益，不在秒级编译时间，而在团队协作时——新人看 import logger; 就知道这文件只用日志功能，不会误读出一堆无关宏定义；重构时改 logger.ixx，不用 grep 全项目确认谁偷偷用了它的私有 log_level_to_string 函数。

C++ 的模块不是语法糖，是逼你重新思考“什么该暴露，什么该隐藏”的契约意识。它不解决所有问题，但把“头文件地狱”里那些靠经验、靠约定、靠运气维系的隐性规则，变成了编译器可验证的显性约束。

下次再看到编译卡住，不妨先问一句：我到底在导入什么？是一堆文本，还是一个契约？