未导出符号在C++20 Modules中天然隔离，完全不可见于其他模块，不参与链接符号表，杜绝宏污染、ODR冲突和同名符号“打架”；static/匿名命名空间因此基本不再需要，因未export即默认私有；export是显式白名单，导出名须人工去重以防ODR错误。
未导出符号在C++20 Modules中天然隔离，不会冲突
模块（Modules）的语义保证：每个模块是一个独立的编译单元，其内部未被 export 的名称（函数、变量、类型、namespace）**完全不可见于其他模块**，也不参与链接期符号表生成。这和传统头文件包含模型有本质区别——没有宏污染、没有重复定义、也没有跨模块的同名符号“打架”问题。
为什么 static 或 anonymous namespace 在模块里基本不用了
在传统 TU（translation unit）中，static 和匿名命名空间是用来防止符号导出、避免 ODR 违规的补救手段；而在模块中，只要你不写 export，所有定义默认就是“模块私有”的，连名字都不会进入任何外部作用域。
-
export是显式白名单，没它就等于没接口 - 模块内定义的
int helper = 42;、void detail::work() { }、甚至整个namespace impl { ... }都不会产生任何可链接符号 - 两个模块各自定义
namespace config { int version = 1; }，互不影响——它们根本不在同一个符号空间里
但要注意：导出符号仍需命名唯一性
一旦你用 export 暴露了一个名字（比如 export void init();），它就会变成模块的公共接口，此时若多个模块都导出了同名函数且被同一翻译单元导入，编译器会报 ODR 错误（C++20 要求导入的同名导出实体必须完全一致）。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 这不是链接冲突，是编译期诊断：Clang/GCC 会在
import时检查签名是否匹配 - 解决方法不是加
namespace，而是确保导出名带模块标识，例如：export void mylib_init();而非裸名init() - 模块名本身不参与导出符号命名（
module mylib;不会让export void f();变成mylib::f），所以导出名必须人工去重
真正容易被忽略的坑：模板定义与隐式实例化
模块中定义的非导出模板（如 template<typename t> T square(T x) { return x * x; }</typename>）虽然没写 export，但如果被其他模块导入并实例化，实例化代码会出现在调用方 TU 中——此时若两个模块都定义了同名同签名的非导出模板，而都被同一 TU 导入，可能引发 ODR 违规。
立即学习“C++免费学习笔记（深入）”；
- 安全做法：模板要么导出（
export template<typename t> ...</typename>），要么彻底放在私有头/模块分区里，确保只被一个模块使用 - 避免在多个模块中重复定义相同工具模板，哪怕它们都没导出
- 用
module :private分区（C++20 后期支持）可进一步限制模板可见范围，但目前主流编译器支持有限
