仅靠namespace无法解决动态库符号重名冲突，因其不影响动态链接时的符号可见性；应采用visibility=hidden、符号前缀、version script或dlopen(RTLD_LOCAL)等机制实现符号隔离。
动态库中同名函数被主程序覆盖怎么办
直接结论：仅靠 namespace 无法解决动态库符号重名冲突。C++ 的 namespace 只影响编译期名称修饰（name mangling），但动态链接时，符号表里最终导出的是未修饰的 C 风格符号（或经 ABI 规则修饰后的符号），namespace 本身不参与符号可见性控制。
典型现象是：两个动态库都导出了 void init()，主程序链接时没报错，但运行时调用的总是后加载/先解析到的那个版本——namespace 完全没起作用。
- Linux 下可用
nm -D liba.so或objdump -T liba.so查看实际导出符号，确认是否真有重名 - Windows 下用
dumpbin /exports liba.dll，注意__declspec(dllexport)函数默认导出 unmangled 名（除非加extern "C"） - 即使函数在
namespace A { void f(); }中，GCC/Clang 默认仍导出类似_Z1fV这样的 mangled 符号；但若主程序用 C 链接方式调用，或动态 dlsym("f")，就只认 unmangled 名
真正可控的符号隔离手段有哪些
核心思路是让每个库的符号在动态链接层面“互相看不见”。不是靠语言特性，而是靠链接器与加载器机制。
-
使用
visibility=hidden+ 显式导出：编译时加-fvisibility=hidden，再对需要暴露的函数加__attribute__((visibility("default")))。这样未标注的符号（包括所有namespace内部函数）默认不导出，从源头减少冲突面 -
为符号加唯一前缀：比如统一用库名缩写，
libfoo_init()、libfoo_process_data()。简单粗暴，但最可靠，尤其适合 C 接口层 -
Linux 下用
version script：通过.map文件精确控制哪些符号导出、是否全局可见。例如LIBFOO_1.0 { global: libfoo_*; local: *; }; -
Windows 下慎用
__declspec(dllexport)全局开关：推荐用模块定义文件（.def）显式列出EXPORTS，避免头文件宏污染导致意外导出
为什么 extern "C" + namespace 组合反而更危险
很多人试图用 extern "C" { namespace A { void f(); } } 来“固定符号名又保留命名空间语义”，这会直接破坏 C++ 名称修饰，导致 f 被导出为纯 C 符号 f，彻底失去类型安全，且和任何其他库里的 f 形成硬冲突。
立即学习“C++免费学习笔记（深入）”；
-
extern "C"会禁用 name mangling，namespace在此上下文中完全失效 - 如果两个库都这么写，
dlsym(handle, "f")拿到的是哪个，取决于加载顺序和符号解析策略（如RTLD_GLOBALvsRTLD_LOCAL） - 更糟的是，C++ 编译器可能允许这种写法，但链接器和运行时不会做任何保护
加载时隔离：dlopen 的 flag 是最后一道防线
当无法修改库源码时，运行时加载策略能缓解问题。关键不是“能不能加载”，而是“符号要不要泄露到全局符号表”。
- Linux 下优先用
dlopen(..., RTLD_LOCAL)：该库的符号不会参与后续dlsym或其他库的符号解析，有效防止污染 - 避免
RTLD_GLOBAL，除非明确需要跨库符号引用（此时必须确保无重名） - Windows 下对应的是
LoadLibrary，它默认行为类似RTLD_LOCAL，但要注意GetProcAddress只能查本库符号，不跨库解析 - 多个库需协作时，建议设计一个中间接口层（如单例管理器），由它统一加载并转发调用，把符号冲突关在内部
真正麻烦的从来不是“怎么写 namespace”，而是“谁在链接时看见了这个符号”。导出控制粒度越细，后期集成越省心。别信编译器警告说“符号已定义”，那只是编译阶段；动态符号冲突往往等到上线压测才突然爆发。
