namespace在DLL中无法解决符号重名冲突，因其仅作用于编译期作用域，不控制链接期导出行为；必须配合__declspec(dllexport)或visibility属性显式控制符号可见性，否则经name mangling导出的符号仍会撞车，尤其在extern "C"约定或跨DLL共享对象时引发ODR违规与未定义行为。
直接用 namespace 隔离不能解决 DLL 工程中的符号重名冲突——它只管编译期作用域，不管链接期导出行为。真正起效的前提是：你同时控制符号可见性，否则 namespace 里的函数仍会以 mangled 名导出，照样撞车。
为什么 namespace 单独用在 DLL 里基本没用
Windows DLL（或 Linux .so）导出的是经过名称修饰（name mangling）的全局符号，比如 libA::init() 和 libB::init() 在符号表里分别是 ?init@libA@@YAXXZ 和 ?init@libB@@YAXXZ，看似不同；但一旦你用了 __declspec(dllexport) 或未加 visibility 控制，这两个符号就都会进导出表。而如果两个 DLL 被同一进程加载，且都导出了同名 C 风格接口（如 extern "C" int init();），那冲突立刻发生——namespace 对 C 链接约定完全无效。
- namespace 不影响 C 链接约定下的符号名：加了
extern "C"就退化成纯名字，libA::init和libB::init都变成init - 即使保留 C++ mangling，若两个 DLL 都导出
libA::helper()和libB::helper()，主程序静态链接时可能不报错，但运行时加载器可能覆盖或混淆解析顺序 - 类的虚函数表地址、静态成员变量等跨 DLL 共享时，ODR 违反会导致未定义行为，崩溃点往往远离冲突源
必须配合 visibility / dllexport 控制导出范围
仅当 namespace 内部符号被明确设为“不导出”，才能真正隔离。关键不是“写在哪”，而是“露给谁看”。
- Windows 下：对非接口函数一律不加
__declspec(dllexport)；接口类/函数显式标记，且命名带模块前缀，如libA_init() - Linux/macOS 下：编译时加
-fvisibility=hidden，再用__attribute__((visibility("default")))只标记真正要暴露的少数符号 - 绝对避免在头文件里写
inline函数体 +__declspec(dllexport)—— 这会让每个包含该头的编译单元都尝试导出同一符号，链接时报multiple definition - 静态库（.lib/.a）场景下，
namespace才真正起作用：因为符号不导出，链接器只取一个定义；但换成 DLL，就得靠导出控制兜底
遇到第三方 DLL 冲突时，namespace 本身无法补救
如果你无法修改冲突 DLL 的源码，namespace 是无能为力的。此时只能从链接/加载层干预：
立即学习“C++免费学习笔记（深入）”；
- 用 Windows 的
LoadLibraryEx+GetProcAddress手动加载并调用，绕过隐式链接和符号解析 - Linux 下用
dlopen(RTLD_LOCAL)加载，确保其符号不进入全局符号表 - 构建时用链接器参数
--allow-multiple-definition（慎用）或--wrap=xxx重定向调用入口 - 用
objcopy --localize-symbol把其中一个库的目标文件里冲突符号转为 local，再重新归档
真正容易被忽略的一点：DLL 模块之间若共享同一个全局对象（比如单例），哪怕名字不冲突，也可能因内存布局或 CRT 实例不同导致访问越界。这时 namespace 不是解药，而是障眼法。
