DLL导出符号冲突的根本原因是C++链接器不为命名空间内的函数自动做导出名隔离，导致同名函数在导出表中碰撞；解决关键是用extern "C"加唯一前缀、DEF文件精确控制或static/inline限制内部符号。
为什么DLL导出符号会冲突？
根本原因不是命名重复本身，而是C++链接器在解析__declspec(dllexport)符号时，不自动做命名空间隔离——即使函数在namespace A里定义，导出的符号名仍是func（非A::func），和全局或其它命名空间里的同名函数撞车。
典型现象：加载多个DLL后调用崩溃、GetProcAddress返回NULL、链接时提示LNK2005: symbol already defined。
关键点：C++的命名空间是编译期作用域，不影响导出符号的链接名；DLL导出表只认修饰后的C风格符号或C++ mangling名，而mangling规则受编译器、调用约定、参数类型共同影响，极易失控。
用extern "C" + 前缀强制隔离符号
最稳定、跨编译器兼容的方式：放弃C++ name mangling，手动加唯一前缀，把命名空间逻辑“搬到名字里”。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
- 在头文件中声明导出函数时，统一加公司/模块缩写前缀，例如：
MYLIB_init()、MYLIB_process_data() - 必须搭配
extern "C"防止mangling：extern "C" { __declspec(dllexport) int MYLIB_init(); __declspec(dllexport) void MYLIB_process_data(int* buf, size_t len); } - 避免在
extern "C"块里使用C++类型（如std::string），否则仍可能触发隐式mangling或ABI不兼容 - 若必须导出类，不要直接导出class，改用工厂函数+纯C接口封装：
__declspec(dllexport) MyLibProcessor* create_processor();
__declspec(dllexport)配合static与inline控制可见性
导出符号冲突常源于“本不该导出的函数被意外导出”，比如内联工具函数、静态辅助函数被__declspec(dllexport)污染了整个翻译单元。
- 对仅在DLL内部使用的函数，**显式加
static**（哪怕在.cpp里定义）：它会抑制符号生成，比依赖链接器优化更可靠 - 对模板或
constexpr函数，用inline而非__declspec(dllexport)：C++17起inline变量/函数天然支持ODR，且不会出现在导出表中 - 检查编译器警告：MSVC开启
/Wall，留意C4251（导出类成员需dll interface）、C4273（不一致的dll linkage） - 慎用
#pragma comment(linker, "/EXPORT:")：它绕过源码控制，容易遗漏或拼错符号名，调试困难
用DEF文件精确控制导出列表
当项目已有大量遗留代码、无法逐个加__declspec，或需要隐藏某些符号时，DEF文件是最底层、最确定的方案。
- 新建
mylib.def，明确列出要导出的符号（不带@序号则由链接器自动分配）：EXPORTS MYLIB_init MYLIB_process_data ; 不写 internal_helper 就不会导出 - 在项目设置中指定DEF文件路径（MSVC：属性 → 链接器 → 输入 → 模块定义文件）
- DEF文件**不识别C++命名空间**，所有符号名必须是链接器看到的最终名：如果是C++函数，得用
dumpbin /exports mylib.dll查真实mangled名（如??$process@H@@YAHH@Z），极难维护 - 因此DEF只推荐用于C接口DLL，或配合
extern "C"使用——此时符号名就是你写的原样
真正麻烦的不是技术选型，而是混合使用多种导出方式：比如头文件用__declspec，又配了DEF文件，还开了自动导出（/EXPORT:ALL）。这时符号优先级混乱，连dumpbin都难理清谁覆盖了谁。动手前先跑一遍dumpbin /exports看实际导出表，比读文档管用十倍。
