仅靠 namespace 无法解决 DLL 符号重名冲突，因其仅影响编译期 name mangling，不控制动态链接时符号可见性；extern "C" + namespace 更危险，因 extern "C" 彻底忽略 namespace 并禁用 name mangling，导致类型不安全与调用约定风险；真正可控方案是链接器层面隔离：Linux 用 -fvisibility=hidden 配合 visibility("default")，Windows 用 .def 文件显式导出带前缀符号，并加载时使用 RTLD_LOCAL 或 LOAD_LIBRARY_AS_DATAFILE 避免全局符号泄露。
仅靠 namespace 无法解决 DLL 符号重名冲突。 它只影响编译期名称修饰（name mangling），不控制动态链接时的符号可见性。两个 DLL 都导出 void init()，主程序调用时拿到的一定是后加载或链接顺序优先的那个——namespace 在这里完全失效。
为什么 extern "C" + namespace 更危险
有人试图写 extern "C" { namespace A { void f(); } } 来“兼顾语义和兼容”，这反而会彻底破坏 C++ 的类型安全：
-
extern "C"禁用 name mangling，f被导出为纯 C 符号f，namespace A彻底被忽略 - 若另一个 DLL 也导出
f，dlsym(handle, "f")或GetProcAddress拿到哪个，取决于加载顺序和RTLD_GLOBAL等策略 - Windows 下甚至可能因调用约定不匹配导致栈损坏
真正可控的导出符号隔离手段
核心思路是让每个 DLL 的符号在动态链接层面“互相看不见”。这不是语言特性问题，而是链接器与加载器机制问题：
- Linux：编译时加
-fvisibility=hidden，再对需暴露的函数加__attribute__((visibility("default")))；未标注的符号（含所有namespace内部函数）默认不进动态符号表 - Windows：禁用全局
__declspec(dllexport)，改用.def文件显式列出EXPORTS，例如：LIBRARY mylib EXPORTS mylib_init = MyNamespace::init@0 mylib_shutdown = MyNamespace::shutdown@0
等号右边必须是dumpbin /symbols查到的真实修饰名，且@0必须匹配签名 - 通用兜底：主程序加载 DLL 时用
dlopen(..., RTLD_LOCAL)（Linux）或LoadLibraryEx(..., LOAD_LIBRARY_AS_DATAFILE)（Windows），避免符号泄露到全局符号空间
验证导出符号是否真被隔离
别信头文件声明，直接查实际导出表：
- Linux：
nm -D liba.so | grep init或objdump -T liba.so | grep init，确认只看到带前缀的mylib_init，没有裸init - Windows：
dumpbin /exports liba.dll，检查输出中是否出现未加前缀的函数名；若看到??0MyClass@@QEAA@XZ这类修饰名，说明没加extern "C"或.def控制，ABI 不稳定 - 若发现冲突符号已存在，优先删掉
__declspec(dllexport)或extern "C"块，再用.def或 visibility 重控，而不是改namespace
最容易被忽略的一点：符号冲突往往不是“有没有定义”，而是“有没有意外导出”。一个 static 函数、一个匿名 namespace 里的辅助逻辑，只要被 __declspec(dllexport) 标记过，就会进导出表——它和 namespace 在不在同一层完全无关。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
