c++动态库导出类会导致名字混淆，因编译器进行name mangling生成含类型/作用域信息的修饰名（如?func@myclass@@qeaaxxz），使c#、python等无法直接调用；extern "c"不能导出类本身，只能导出c兼容函数，需封装为create/destroy/do_something等纯c接口。
为什么C++动态库导出类会导致名字混淆
因为C++支持函数重载、命名空间、模板等特性，编译器会对符号名做name mangling（名字修饰），生成一长串带类型/作用域信息的内部符号。DLL导出类的成员函数时，若不干预，dumpbin /exports看到的函数名类似 ?func@MyClass@@QEAAXXZ，其他语言（如C#、Python ctypes）或C代码根本没法直接调用。
extern "C"不能直接导出C++类，但能导出C风格接口
extern "C"只禁用名字修饰，但它要求函数签名是C兼容的：不能含引用、重载、类成员、模板等。所以你不能写 extern "C" class MyClass { ... };——这语法错误。
正确做法是封装一层C接口：
- 在DLL中定义纯C函数，比如
MyClass* create_myclass();、void myclass_do_something(MyClass* obj);、void destroy_myclass(MyClass* obj); - 这些函数用
extern "C"声明并导出（配合__declspec(dllexport)或 .def 文件） - 类本身保留在DLL内部，不暴露给外部模块
示例头文件（供调用方使用）：
#ifdef __cplusplus
extern "C" {
#endif
<p>__declspec(dllimport) void<em> create_myclass();
__declspec(dllimport) void myclass_do_something(void</em> obj);
__declspec(dllimport) void destroy_myclass(void* obj);</p><h1>ifdef __cplusplus</h1><p>}</p><h1>endif</h1><p></p>
导出类本身？用模块定义文件（.def）绕过name mangling
如果必须导出类的成员函数（比如供另一份C++代码链接），又不想让调用方写C风格包装，可以用 .def 文件显式指定导出符号名，但前提是：你得知道修饰后的名字。
操作步骤：
- 先编译DLL（不加任何导出声明），用
dumpbin /symbols mylib.obj查看实际修饰名，比如??0MyClass@@QEAA@XZ（构造函数） - 新建
mylib.def，写入：EXPORTS ??0MyClass@@QEAA@XZ @1 ??1MyClass@@QEAA@XZ @2 ?do_work@MyClass@@QEAAXXZ @3
- 链接时加上
/DEF:mylib.def
缺点明显：修饰名随编译器版本、调用约定（__cdecl/__stdcall）、成员函数const/volatile限定变化，极难维护。VS2019和VS2022生成的同一段代码修饰名可能不同。
更现代、更安全的选择：抽象接口 + 工厂函数
真正工业级方案不是硬导出类，而是定义纯虚基类（ABI稳定），用 extern "C" 导出工厂函数创建实例：
- 接口类只含 public virtual 函数、无数据成员、无虚析构以外的虚函数（确保vtable布局简单）
- 工厂函数返回
IInterface*，调用方通过接口指针调用，无需知道实现类名 - 所有函数用
__cdecl，避免调用约定差异导致栈破坏
关键点：接口头文件里不出现 __declspec，导出逻辑全收在DLL源码内；调用方只需链接lib或LoadLibrary+GetProcAddress，完全不依赖名字修饰。
容易被忽略的是：即使用了 extern "C"，若DLL和EXE用不同CRT（如MTd vs MD），std::string 或 std::vector 作为参数仍会崩溃——跨DLL边界传递C++标准库对象永远是雷区。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
