根本原因是exe与dll拥有独立c++运行时堆，dll中new的内存被exe delete或访问会导致堆损坏；正确做法是仅导出纯c接口，内存分配/释放严格限定在dll内。
为什么DLL里new出来的单例在EXE里调用会崩溃
根本原因是：每个模块（EXE 和 DLL）都有独立的 C++ 运行时堆，new 在 DLL 中分配的内存，若被 EXE 直接 delete 或访问其内部指针（比如 std::string 成员），极大概率触发堆损坏或访问违规。这不是“单例写得不对”，而是跨模块对象生命周期管理失控。
常见错误现象包括：Access violation reading location 0xCCCCCCCC、HEAP CORRUPTION DETECTED、std::string::_Mypair._Myval2._Bx._Buf 读取异常——这些都指向同一块内存被不同堆管理。
- 不要在 DLL 中返回裸指针（如
MySingleton*）让 EXE 自行delete - 不要在单例内部存储跨模块传递的 STL 对象（如
std::vector<int></int>），除非确保 ABI 和堆完全一致（MSVC 同版本 + /MD） - 导出类本身（
class __declspec(dllexport) MySingleton）不能解决堆隔离问题，只会让问题更隐蔽
正确做法：只导出纯 C 接口 + 内存由单一模块管理
绕过 C++ 对象模型和堆耦合的最可靠方式，是把单例当作“C 风格资源”来用：构造/析构/访问全部通过函数指针完成，且所有内存分配/释放严格限定在 DLL 内部。
实操建议：
- DLL 导出三个 C 函数：
MySingleton_Create()（返回void*）、MySingleton_Destroy(void*)、MySingleton_DoWork(void*, int)；全部用extern "C" __declspec(dllexport)声明 - 单例实例用静态局部变量实现（线程安全，C++11 起 guaranteed）：
static MySingleton& instance() { static MySingleton s; return s; } -
Create()返回&instance()（地址），Destroy()什么也不做（因为静态变量生命周期由 DLL 卸载时自动管理） - 所有成员函数参数/返回值避开 STL 容器、异常、虚函数表；基本类型、固定大小数组、
const char*（需保证生命周期）可安全传递
如果必须导出 C++ 类：/MD 是硬性前提，且要禁用隐式链接
当项目已重度依赖 DLL 导出类（如插件架构），强行改 C 接口成本过高，则必须确保：EXE 和所有 DLL 使用完全相同的 CRT，即全部编译选项为 /MD（动态链接 MSVCRT），而非 /MT。否则 std::string 的内部缓冲区可能在不同堆上分配，哪怕地址看起来一样也会崩溃。
关键细节：
- 检查每个模块的链接器输入：确认
msvcp140.dll、vcruntime140.dll等版本号完全一致（可用dumpbin /dependents your.dll） - 禁止使用隐式链接（
#pragma comment(lib, "xxx.lib")），改用显式LoadLibrary+GetProcAddress获取函数地址——避免链接时混入不同 CRT 版本的存根 - 导出类中避免内联函数体（尤其是含
std::string构造的），因为内联代码会在调用方模块展开，导致堆不一致 - 导出类的析构函数必须为
virtual，且定义在 DLL 内（不能 inline），否则 EXE 调用delete会走错析构路径
符号可见性与 __declspec(dllimport) 的实际影响
__declspec(dllimport) 不是“可选优化”，而是 Windows 下调用 DLL 函数的正确方式。没加它，链接器会生成 thunk 跳转桩（extra indirection），但更严重的是：若头文件在 EXE 和 DLL 中重复定义（比如都用了 __declspec(dllexport)），会导致 ODR 违反，sizeof(MySingleton) 在两边计算结果可能不同（因模板实例化或 vtable 偏移差异）。
推荐模式：
- 定义宏统一控制：
#ifdef BUILDING_MYDLL→#define MYDLL_API __declspec(dllexport)；否则 →#define MYDLL_API __declspec(dllimport) - 类声明前加
MYDLL_API，但仅对“需要跨模块使用的 public 成员函数”生效；私有成员、静态数据成员不要导出 - 全局变量（如
extern MYDLL_API int g_ConfigFlag）同样适用该规则，但强烈建议改用 getter/setter 函数替代——变量地址跨模块不可靠
真正容易被忽略的点是：即使你只导出一个函数，只要它返回了 C++ 对象（非指针），就隐式要求调用方和实现方的 ABI 完全对齐——这比导出类更危险，因为编译器可能对返回值做 RVO/NRVO，而不同模块对“是否省略拷贝”的判断逻辑未必一致。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
