命名空间在动态库中“失效”是因为它仅作用于编译期，链接器处理的是名称修饰后的底层符号；若存在extern "C"导出或未隐藏的C风格函数，仍会引发符号冲突。
命名空间本身不能解决动态库导出符号名冲突——这是最常被误解的一点。C++命名空间只在编译期起作用，而链接器看到的是经过名称修饰（name mangling）后的底层符号，比如 _ZN7MyLibA6helperEv 和 _ZN7MyLibB6helperEv 看似不同，但若两个库都导出了未加修饰的 C 风格函数（如 helper()），或使用了 extern "C"，那冲突就真实存在。
为什么 namespace 在动态库中“失效”了
当你写 namespace MyLibA { void func(); }，编译器会生成带命名空间前缀的修饰名；但如果某个头文件里写了 extern "C" { void func(); }，或者你用 __attribute__((visibility("default"))) 导出了一个非命名空间封装的 C 函数，它就会以原始名 func 进入动态库的导出符号表。此时，另一个库只要也导出 func，链接器就会按优先级规则选一个，而不是报错。
常见错误现象：
- 程序运行时调用了“不该调用”的
func，调试打印没出现，但逻辑走通了 -
nm -D libA.so | grep func和nm -D libB.so | grep func都显示T func - 用
LD_DEBUG=symbols ./a.out可见重复符号被“覆盖”
真正有效的隔离：从编译到链接全程控制
要让命名空间“落地”为链接层的安全，必须配合符号可见性策略，否则只是纸面隔离。
立即学习“C++免费学习笔记（深入）”；
- 所有 C++ 接口统一放在命名空间内，且**禁用 extern "C" 暴露同名 C 符号**
- 编译时加
-fvisibility=hidden，默认隐藏所有符号 - 仅对明确需要跨库调用的接口，用
__attribute__((visibility("default")))显式导出，例如：namespace MyLibA { __attribute__((visibility("default"))) void public_api(); } - 避免在头文件中直接定义 inline 函数体（尤其含静态局部变量），否则可能在多个库中产生重复强符号
当必须共存同名 C 符号时：用前缀 + static + dlopen 隔离
如果你无法修改第三方库，而它导出了裸 C 函数（如 init(), parse()），又必须和自己的同名函数共存，硬靠命名空间没用，得换思路：
- 自己实现的 C 函数一律加前缀，如
mylib_init()，不依赖命名空间 - 内部辅助函数全用
static修饰，确保不会进入符号表 - 对冲突的第三方库，改用
dlopen(..., RTLD_LOCAL | RTLD_DEEPBIND)加载，避免其符号泄漏到全局符号空间 - 调用时不用
dlsym(RTLD_DEFAULT, "init")，而是用句柄显式获取：void* h = dlopen("libconflict.so", RTLD_LOCAL); auto f = (void(*)())dlsym(h, "init"); // 绑定到该句柄，不污染全局
最容易被忽略的是：即使你写了完美的命名空间，只要有一个 extern "C" 块、一个漏掉的 static、或一次 RTLD_GLOBAL 的 dlopen，整个隔离就失效了。符号冲突不是“有没有命名空间”的问题，而是“有没有让每个符号在链接器眼里真正唯一”的问题。
