根本原因是__declspec(dllexport)依赖预处理器宏定义时机与一致性，若DLL项目未定义导出宏（如MYLIB_EXPORTS）而调用方误用，会导致符号导出失效或LNK2005重复定义；必须通过条件宏隔离、统一运行时库（/MD）、显式导出类及虚函数、避免模板跨DLL使用，并用dumpbin验证真实导出状态。
为什么 __declspec(dllexport) 在跨项目时经常失效
根本原因不是语法写错了，而是导出控制依赖于预处理器宏的定义时机和一致性。一个项目里定义了 MYLIB_EXPORTS 宏来触发 __declspec(dllexport)，但另一个项目没定义它，或者定义了却没参与编译——结果就是头文件里实际展开的是 __declspec(dllimport)，而链接时又找不到对应符号。
- 确保导出宏只在构建 DLL 的项目中定义（如 Visual Studio 项目属性 → C/C++ → 预处理器 → 预处理器定义）
- 不要在头文件里用
#ifdef _WIN32直接硬写__declspec(dllexport)；必须通过中间宏隔离，例如：#ifdef MYLIB_EXPORTS<br> #define MYLIB_API __declspec(dllexport)<br>#else<br> #define MYLIB_API __declspec(dllimport)<br>#endif
- 如果使用 CMake，导出宏必须通过
target_compile_definitions(mylib PRIVATE MYLIB_EXPORTS)注入到 DLL 构建目标，而非全局设置
类成员函数导出时 virtual 和模板引发的符号丢失
普通函数加 __declspec(dllexport) 就能导出，但类的虚函数表（vtable）和模板实例化是隐式生成的，不会自动导出，尤其当类声明在头文件、实现放在 .cpp 里时，DLL 可能只导出了声明，没导出 vtable 或具体函数体。
- 对导出类，必须显式导出整个类：
class MYLIB_API MyClass { ... };，不能只导出个别成员函数 - 虚析构函数必须有定义（哪怕空实现），且必须在 DLL 的 .cpp 文件中提供，否则调用方可能崩溃
- 模板类不支持跨 DLL 导出——
std::vector<int>可以传，但自定义模板类如MyContainer<float>必须在头文件中完整定义（即 inline 实现），否则调用方无法实例化
混用 /MD 和 /MT 导致 DLL 加载失败或堆异常
错误现象是程序启动时报 0xC0000005 或 invalid heap pointer，根源在于 CRT（C 运行时）内存管理不一致：DLL 用 /MD（动态链接 CRT），而主程序用 /MT（静态链接 CRT），导致 new/delete 跨模块调用时操作了不同堆。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 所有参与同一进程的模块（EXE + 所有 DLL）必须统一使用
/MD（Release）或/MDd（Debug） - 检查每个项目的属性 → C/C++ → 代码生成 → 运行时库，确认值完全一致
- 第三方库（如 Boost、OpenSSL）若提供静态库版本，务必确认其编译时也用了匹配的运行时选项，否则直接链接会埋雷
调试时看不到导出符号？用 dumpbin /exports 和 Dependency Walker 验证真实状态
头文件写了 MYLIB_API，不代表符号真进了 DLL。Windows 下导出符号受名称修饰（name mangling）、.def 文件、链接器开关等多重影响，仅靠源码无法判断最终输出。
立即学习“C++免费学习笔记（深入）”；
- 用命令行验证：
dumpbin /exports mylib.dll，看函数名是否出现（注意 C++ 名称会被修饰，C 风格导出需加extern "C"） - 如果只看到一堆问号或乱码，大概率是没加
extern "C"，或导出宏未生效导致链接器没处理该符号 -
Dependency Walker（或更现代的Dependencies工具）可加载 DLL 并显示实际解析出的符号，比 IDE 的“转到定义”可靠得多
最常被忽略的一点：DLL 的导出可见性不是“写出来就生效”，它是一整套构建链协同的结果——宏定义、编译选项、链接器设置、运行时库模式，缺一不可。任何一个环节错位，都会让符号在某个环节消失，而且往往不报错，只在运行时崩掉。
