导出类必须用宏控制__declspec(dllexport/dllimport)，虚函数需类级修饰，模板类不可直接导出，构造/析构函数须公有且统一导出，跨dll传递c++对象存在abi风险。
导出类时必须用宏控制 __declspec(dllexport) 和 __declspec(dllimport)
直接硬写 __declspec(dllexport) 或 __declspec(dllimport) 到类声明里会出问题：DLL 工程要导出，而使用 DLL 的工程必须导入，二者不能共存于同一份头文件中。正确做法是用宏切换——编译 DLL 时定义一个宏（比如 BUILDING_MY_DLL），头文件里据此展开不同声明：
#ifdef BUILDING_MY_DLL
#define MY_DLL_API __declspec(dllexport)
#else
#define MY_DLL_API __declspec(dllimport)
#endif
<p>class MY_DLL_API MyClass {
public:
MyClass();
void doSomething();
};</p>
漏掉这个宏切换，会导致调用方链接失败（LNK2019：找不到符号），因为编译器看到的是 dllexport 声明却没生成对应实现，或反过来把导入当成了导出。
类里有虚函数时，__declspec(dllexport) 必须加在类声明上，不能只加在成员函数上
虚函数表（vtable）是类级别的，DLL 导出时需要把整个类的 vtable 暴露出去。如果只对单个虚函数加 __declspec(dllexport)，链接器不会导出 vtable，调用方 new 对象后调用虚函数大概率崩溃（访问野指针）。
常见错误写法：
class MyClass { // ❌ 没加 dllexport，vtable 不导出
public:
virtual void foo(); // ✅ 单独加了，但没用
};
// 编译成 DLL 后，调用方调用 foo() 会 crash
正确写法：
class MY_DLL_API MyClass { // ✅ 类整体导出，vtable 自动导出
public:
virtual void foo(); // 不需要再单独加 dllexport
};
非虚成员函数可以单独导出，但虚函数必须靠类级修饰生效。
模板类不能直接用 __declspec(dllexport) 导出
模板实例化发生在编译期，而 __declspec(dllexport) 是链接期机制。对模板类加 MY_DLL_API 无效，DLL 中不会生成任何实例代码，调用方链接时必然报 LNK2019。
可行方案只有两个：
- 显式实例化：在 DLL 源文件中写
template class MY_DLL_API MyTemplate<int>;</int>，告诉编译器“请为int版本生成并导出” - 不导出模板类，改用非模板接口（如基类指针 + 工厂函数）或头文件分发（即模板定义全放在头文件里，不进 DLL）
试图绕过这个限制（比如把模板声明套上 dllexport）只会让编译通过、运行时报错，且错误位置极其隐蔽。
导出类的构造/析构函数必须可被 DLL 外访问，否则对象生命周期管理会出错
如果类的构造函数或析构函数是 private/protected，或没加 MY_DLL_API，那么调用方无法在堆上 new/delete 对象——即使类声明带了 dllexport，私有函数本身未导出，链接阶段就失败。
更危险的是：如果构造函数导出了但析构函数没导出（或反之），new 成功但 delete 崩溃，因为 delete 会尝试调用 DLL 外不可见的析构逻辑。
稳妥做法：
- 确保公有构造/析构函数都随类一起被
MY_DLL_API修饰 - 避免在类内定义 inline 析构函数（尤其含资源释放逻辑），因为 inline 版本可能在调用方编译，导致资源在两处释放
- 若需精细控制对象销毁，提供导出的工厂函数和销毁函数，例如
MyClass* createMyClass(); void destroyMyClass(MyClass*);
跨 DLL 边界传递 C++ 对象，本质是把内存布局和 ABI 绑死在特定编译器/版本上。哪怕语法全对，换了个 MSVC 小版本或开了不同编译选项（如 /MD vs /MT），也可能静默崩溃。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
