仅靠 namespace 无法解决 DLL 符号导出冲突，因其不控制链接期符号名和动态解析顺序；真正有效的是编译期可见性控制（如 -fvisibility=hidden 或 __declspec(dllexport) 精确标注）、导出符号唯一化（如模块前缀或 .def 文件别名）、以及加载策略协同（如 RTLD_LOCAL 或进程隔离）。
仅靠 namespace 无法解决 DLL 符号导出冲突——它不控制链接器看到的符号名，也不影响动态加载时的符号解析顺序。真正起效的是编译期可见性控制、导出命名唯一化和加载策略协同。
为什么 __declspec(dllexport) 默认行为是冲突根源
Windows 下未加修饰的 __declspec(dllexport) 会把函数以 unmangled 名（如 init）导出到 DLL 的导出表中，哪怕它定义在 namespace MyLib { void init(); } 里。两个 DLL 都导出 init，主程序调用 GetProcAddress(hDll, "init") 时，结果取决于加载顺序和 LoadLibrary 的解析策略，不是编译期报错，而是运行时静默覆盖。
- 用
dumpbin /exports mylib.dll查看真实导出名，确认是否含命名空间前缀；若显示init而非?init@MyLib@@YAXXZ，说明被降级为 C 风格导出 - 默认导出所有带
dllexport的函数，包括内联辅助函数、模板显式实例化点——只要没加static或匿名命名空间，就可能意外暴露 - 头文件中若用宏批量开关
dllexport（如#define MYLIB_API __declspec(dllexport)），极易因宏作用域污染导致本该隐藏的函数也被导出
extern "C" + namespace 是危险组合
写成 extern "C" { namespace MyLib { void process(); } } 看似“兼顾语义与兼容”，实则彻底失效：extern "C" 强制禁用 name mangling，namespace 信息被丢弃，最终导出纯符号 process。此时若另一个库也导出 process，冲突不可避。
- 所有
extern "C"导出函数必须手动加唯一前缀，如acme_v2_process()，且该前缀要真实出现在函数定义、声明和调用方代码中 - 禁止用
#define process acme_v2_process做头文件兼容——这会让调用方误以为接口是标准 C 函数，且仍向全局符号表注入acme_v2_process，未解决本质问题 - 若需对接第三方 C 库（如
libpng），优先查其是否提供PNG_EXPORT类机制；否则只能静态链接或用LoadLibrary+GetProcAddress显式隔离句柄
用 .def 文件精确控制导出符号与别名
.def 文件是 Windows 下绕过 C++ name mangling、强制指定导出名的最可靠方式，尤其适合需要稳定 ABI 或供 C 端调用的场景。它不依赖编译器属性，链接器直接按字面匹配。
立即学习“C++免费学习笔记（深入）”；
- 创建
mylib.def，内容必须包含LIBRARY和EXPORTS段，例如：LIBRARY mylib EXPORTS init@1 = MyLib::Core::init@0 shutdown@2 = MyLib::Core::shutdown@0
- 等号左边是调用方看到的名字（如
init），右边是 dumpbin 查到的真实 mangled 名（如?init@Core@MyLib@@SAXXZ），@后数字代表调用约定和参数字节数，必须严格匹配 - 不写等号则直接导出 mangled 名，但名字不可读、不稳定；加别名后，调用方无需关心命名空间，只需
GetProcAddress(hDll, "init") - 链接时需在项目设置中指定
/DEF:mylib.def，否则 .def 文件被忽略
加载时用 RTLD_LOCAL 或独立进程隔离符号污染
即使导出符号已隔离，多个 DLL 同时加载到同一进程仍可能因全局符号表污染引发覆盖。Linux 下可用 dlopen(..., RTLD_LOCAL) 让符号仅对当前 handle 可见；Windows 下无直接等价机制，需更激进手段。
- Linux：主程序调用
dlopen("libA.so", RTLD_LOCAL)后，libA.so中的符号不会参与后续dlsym的全局查找，避免与libB.so冲突 - Windows：无
RTLD_LOCAL等价物，但可改用 COM 接口或命名管道通信，将插件逻辑放入独立子进程，通过 IPC 调用——代价高，但彻底隔绝符号空间 - 排查已加载 DLL 的符号冲突：运行时设环境变量
LD_DEBUG=symbols（Linux）或用 Process Explorer 查看模块导入/导出表，定位重复符号来源
最易被忽略的点是：符号冲突往往不发生在编译期，而是在多 DLL 同时加载、且都导出未加前缀的 C 风格函数时才暴露。不要依赖 namespace 的“看起来安全”，必须从编译选项（-fvisibility=hidden / /DEFAULTLIB:...LIB）、导出定义（.def / extern "C" 前缀）、加载方式（RTLD_LOCAL / 进程隔离）三处同时控制。
