命名空间重名不报错，但extern "c"导出时会因裸名冲突导致运行崩溃；必须用模块前缀+visibility=hidden控制符号可见性。
命名空间重名本身不构成编译或链接错误，namespace 之间互不影响；真正出问题的是——你误以为加了 namespace 就能隔离导出符号，结果动态库加载时还是符号冲突。
为什么 namespace 重名不报错，但运行时却崩了
因为 namespace 只在编译期起作用，它影响的是 name mangling（比如生成 _ZN6MyLib7processEv 这样的修饰名），但不会阻止符号被导出。只要两个动态库都导出了同名的 C 风格函数（比如都用 extern "C" 导出 init()），链接器就只看到裸名 init，必然冲突。
-
namespace A { void f(); }和namespace B { void f(); }在各自源码里完全合法，编译无错 - 但如果都用
extern "C"导出f()，且没加前缀，最终导出的都是f - Linux 下用
readelf -Ws liba.so | grep FUNC | grep GLOBAL能一眼看出重复的裸名 - Windows 下用
dumpbin /exports a.dll查看，若出现多个同名f，就是隐患
extern "C" 导出时 namespace 完全失效，必须加前缀
一旦用了 extern "C"，C++ 的 name mangling 就被禁用，namespace 对导出符号名零影响。此时唯一可靠的做法是人工制造唯一性。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 所有对外导出的 C 接口，命名格式强制为
模块名_功能名，例如：acme_v2_init()、acme_v2_log_write() - 禁止用宏替换“伪装”前缀，如
#define init acme_v2_init—— 这仍会让头文件暴露裸名init，调用方可能误用 - 封装函数体内再调用真正的命名空间实现：
return Acme::V2::Config::load(); - 导出声明必须显式带属性：
extern "C" __attribute__((visibility("default"))) void acme_v2_init();
编译期默认导出所有非 static 符号，必须关掉
GCC/Clang 默认把所有非 static 全局函数、变量都放进动态符号表，哪怕它们在不同 namespace 里。这是多数冲突的根源。
- 统一在编译选项中加
-fvisibility=hidden，让所有符号默认不可见 - 定义导出宏：
#define API_EXPORT __attribute__((visibility("default"))) - 仅对真正需要跨库调用的接口加该宏，例如：
API_EXPORT void acme_v2_init(); - 内部辅助函数、工具类、未标记的
namespace成员，自动被隐藏，不会进入.so的符号表 - CMake 中推荐写法：
target_compile_options( PRIVATE -fvisibility=hidden )
匿名命名空间只能保翻译单元内安全
如果你只是想避免本文件里的函数被其他模块链接到，用匿名命名空间最干净，但它对导出符号无约束力。
- 写法：
namespace { void internal_helper(); }，定义也必须在同一匿名块内 - 验证方式：
nm -C file.o | grep internal_helper，输出中应含l或L（LOCAL），而非T（TEXT/global） - 注意：匿名命名空间不能用于头文件，否则每个包含它的
.cpp都会生成一份副本，违反 ODR - 它不解决多模块间的导出冲突，只帮你守住“不导出”的底线
真正难的不是写 namespace，而是判断哪些符号必须导出、以什么形式导出、是否要兼容 C、以及上线前有没有用 readelf 或 dumpbin 实锤检查过导出表——这些步骤漏掉任何一环，namespace 再工整也没用。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
