老项目迁移。
最怕两件事。
第一。
一次性大改。
第二。
改完没人敢维护。
Modules 很诱人。
但它不是“全量替换 #include”那么简单。
当年：我们也想把 include 整理干净
很多团队都干过。
“清理 include”。
把头文件分层。
把宏收拾掉。
一开始很有希望。
到后面就会遇到现实。
模板。
平台差异。
第三方库。
以及各种历史包袱。
线上啪一下：你把一个核心头文件动了，所有人都编译不过
这类事故很常见。
你动的是“最基础的那个头”。
它被所有地方 include。
你一改。
全世界都炸。
所以迁移策略必须保守。
阶段 1：先识别边界，别急着写 export
先挑一个边界清晰的库。
比如 util。
它对外只有少量 API。
内部实现很杂。
这个最适合先模块化。
阶段 2：把“稳定 API”先变成 module interface
export module util;
export int foo();
export int bar();
这一步的目的。
是让你先有一个稳定合同。
不需要一开始就追求完美。
阶段 3：逐步把 include 从使用方挪走
你会发现一个收益。
使用方不再 include 一堆头。
只 import 一个模块。
依赖会更干净。
阶段 4：处理“最难的那几类”
模板库。
宏很重的老代码。
以及和构建系统绑死的头文件布局。
这些不是靠语法解决。
它靠工程取舍。
关键结论
迁移 Modules 的正确姿势。
是先小范围吃到收益。
再扩大。
小结
别把 Modules 当宗教。
把它当一次“依赖治理”。
你迁移的是边界。
不是关键字。