Clang等编译器对同名命名空间采用合并式处理，多文件中同名命名空间自动合并为同一作用域；头文件声明需完整限定，.cpp中定义须显式限定或置于对应命名空间内；匿名命名空间仅限本文件有效；-fvisibility=hidden需显式启用才能控制符号导出。
多个 .cpp 文件共用同一个命名空间，直接写就行
Clang（以及 GCC、MSVC）对命名空间的处理是“合并式”的：只要命名空间名相同，无论定义在几个文件里，编译器都会把它们视为同一作用域。你不需要做任何特殊操作，也不用加 extern 或 import。
常见错误是以为必须在一个头文件里集中定义整个 namespace，结果把所有类/函数硬塞进一个 utils.h，导致头文件臃肿、依赖爆炸。
- 在
math_ops.cpp里写：namespace mylib::math {<br> int add(int a, int b) { return a + b; }<br>} - 在
math_const.cpp里写：namespace mylib::math {<br> constexpr double PI = 3.1415926;<br>} - Clang 编译时会自动合并这两个
mylib::math块，最终导出符号为_ZN6mylib4math3addEii和_ZN6mylib4math2PIE
头文件中声明，.cpp 中定义，别漏掉 namespace 限定
头文件负责对外暴露接口，必须用完整限定名或显式进入命名空间；而实现文件里如果直接写函数体，不套 namespace，就会落到全局作用域——这是链接失败的高频原因。
典型错误写法：
// utils.h<br>namespace mylib { void log(const char*); }<br><br>// utils.cpp ← 错！没包在 namespace 里<br>void log(const char*) { /* ... */ } // 这是全局 log，不是 mylib::log
- 正确做法一（头文件声明 + .cpp 内限定）：
// utils.cpp<br>namespace mylib {<br> void log(const char* msg) { /* ... */ }<br>} - 正确做法二（更推荐，避免嵌套缩进）：
// utils.cpp<br>void mylib::log(const char* msg) { /* ... */ }—— 注意：这要求utils.h中的声明已位于mylib内，且 Clang 版本 ≥ 7（支持这种跨文件限定定义） - 头文件中禁止写
using namespace mylib;，否则包含它的任何源文件都会污染全局作用域
匿名命名空间只在当前 .cpp 有效，别指望跨文件共享
如果你在 helper.cpp 里写了 namespace { void internal_init(); }，那这个函数只对该文件可见，Clang 不会把它放进符号表，其他文件也根本链接不到它——这不是 bug，是设计意图。
Clang 22.1.3
下载
Clang 22.1.3 Windows 64 位历史版本安装包，适合旧项目兼容、LLVM/Clang 工具链回退、编译行为对比、链接问题复现和 C/C++ 构建环境维护。
容易踩的坑是误以为“匿名 namespace = private namespace”，试图靠它在多个文件间传递内部状态：
- ❌ 错误：在
a.cpp和b.cpp都定义namespace { int counter = 0; }，然后期望它们共享同一个counter→ 实际上是两份独立变量 - ✅ 正确：需要跨文件共享的内部状态，应定义在具名 namespace 下并设为
static，或改用单例/extern 变量（但需谨慎） - 验证方式：用
nm -C helper.o | grep internal_init，输出带l（local）或L（debug）标识才对；若出现T（text/global），说明没进匿名空间
Clang 编译多文件时，-fvisibility=hidden 对命名空间没用
命名空间本身不影响符号可见性。Clang 默认导出所有非 static 全局符号，哪怕它们在 mylib::detail:: 这种深层嵌套 namespace 里——只要没加 visibility 属性，照样进动态符号表，可能引发 DLL 冲突。
真正起作用的是编译选项和属性标注：
- 必须加
-fvisibility=hidden（Clang/GCC 通用），否则 namespace 包裹毫无隔离效果 - 对外接口用宏封装：
#define MYLIB_API __attribute__((visibility("default")))<br>namespace mylib {<br> MYLIB_API void init(); // ← 这个才导出<br> void internal_helper(); // ← 默认 hidden，不导出<br>} - 别信“用了 namespace 就安全了”——很多团队线上崩溃就栽在这点上
实际工程中，最常被忽略的是：命名空间组织解决的是编译期名字冲突，而动态库场景下的符号碰撞是链接期可见性问题，两者层级不同，不能互相替代。
