不能直接用LoadLibrary调用C++类方法，因DLL仅导出函数符号，不包含类布局、虚表及name mangling等私有类型信息；GetProcAddress返回裸函数地址，无法处理this指针、vtable初始化等，强制转换为成员函数指针将导致崩溃或未定义行为。
为什么不能直接用 LoadLibrary 调用类方法
因为 DLL 导出的是函数符号，不是 C++ 类的完整类型信息——编译器生成的类布局、虚表、name mangling 都是模块私有的。LoadLibrary + GetProcAddress 只能拿到裸函数地址，没法构造对象、调用成员函数（包括 this 指针传递、vtable 初始化等）。强行 cast 成成员函数指针会崩溃或未定义行为。
可行方案：导出工厂函数 + 纯虚接口
这是 Windows 下最稳定、跨编译器兼容的做法。核心是把类的实现细节完全隔离在 DLL 内，只暴露抽象接口和创建/销毁函数。
示例步骤：
- DLL 中定义纯虚基类（如
IWorker），不带成员变量、不内联、用__declspec(dllexport)导出其声明（但不导出实现） - DLL 导出两个 C 风格函数：
CreateWorker()返回IWorker*，DestroyWorker(IWorker*)负责释放 - 主程序用
LoadLibrary加载 DLL，再用GetProcAddress获取这两个函数地址，调用后得到接口指针 - 后续所有操作都通过
IWorker接口调用，不依赖具体类名或内存布局
注意：DLL 和主程序必须使用相同的 ABI（比如都用 MSVC 2019 x64、相同的运行时链接方式 /MT 或 /MD），否则 new/delete 不匹配会导致内存错误。
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
GetProcAddress 找不到函数？检查导出符号
常见原因是函数名被 C++ name mangling 扭曲了。解决方案只有两个：
- 在 DLL 的 .def 文件里显式列出导出函数名（如
CreateWorker），确保是干净的 C 符号 - 或在函数声明前加
extern "C"（如extern "C" __declspec(dllexport) IWorker* CreateWorker();），禁用 mangling
验证导出符号是否正确：用 dumpbin /exports your.dll 查看实际导出列表。如果看到类似 ?CreateWorker@@YAPAVIWorker@@XZ 就说明没加 extern "C"，GetProcAddress 肯定失败。
避免内存管理陷阱：谁分配谁释放
DLL 里的对象必须由 DLL 自己分配和释放，主程序不能用 delete 直接释放接口指针——因为 DLL 和 EXE 可能用了不同的堆（尤其静态链接 CRT 时）。
- 所有对象生命周期必须由 DLL 提供的函数控制（如
CreateWorker/DestroyWorker） - 接口中不要返回裸指针或引用到 DLL 内部数据；如需返回字符串，用
const char*+ 明确文档说明生命周期，或改用BSTR/std::string（但需保证 DLL/EXE 的std::stringABI 兼容） - 如果 DLL 使用了 STL 容器作为接口参数（如
std::vector<int>），务必确保两边编译选项一致（_HAS_ITERATOR_DEBUGGING、_SECURE_SCL等），否则迭代器失效或 size() 崩溃
真正麻烦的从来不是“怎么调”，而是“对象在哪块内存里、谁负责清理、类型信息怎么对齐”。这些细节漏掉一个，程序可能跑几天才 crash。
