C++ DLL符号导出需显式声明__declspec(dllexport)且宏定义严格同步：DLL构建时定义BUILDING_MYLIB，调用方取消；类整体加导出宏，模板须显式实例化；C接口用extern "C"禁用名称修饰；用dumpbin验证导出符号。
在大型跨工程项目中，C++动态库（Windows下DLL）因符号导出可见性控制不当，常导致链接失败、运行时崩溃、同名符号意外覆盖或调试信息丢失——这些问题往往在集成测试阶段才暴露，排查成本极高。
理解DLL符号导出的本质约束
Windows DLL不默认导出任何符号；未显式声明为__declspec(dllexport)的函数/类/变量，在生成的.lib导入库中不会生成对应条目，调用方链接时必然报LNK2019。
若仅用#ifdef BUILDING_MYLIB宏包裹__declspec(dllexport)，但忘记在调用工程中定义MYLIB_EXPORTS或等效宏，会导致所有符号被当作__declspec(dllimport)处理，而实际DLL中并未导出——此时链接通过，运行时加载失败并弹出“找不到指定程序”错误。
【必须确保导出宏定义与编译配置严格同步：构建DLL时定义BUILDING_MYLIB，使用DLL时取消该定义】
立即学习“C++免费学习笔记（深入）”；
统一管理导出宏的头文件方案
方法一：单头文件+条件宏判别
新建mylib_export.h，内容如下：
#pragma once
#ifdef _WIN32
# ifdef BUILDING_MYLIB
# define MYLIB_API __declspec(dllexport)
# else
# define MYLIB_API __declspec(dllimport)
# endif
#else
# define MYLIB_API
#endif
此方案要求所有参与构建的工程（DLL本身和所有调用方）都包含该头文件，并且DLL工程必须在项目设置中添加预处理器定义BUILDING_MYLIB。漏定义则全部符号按dllimport处理，运行时报错。
避免类成员函数隐式不可导出的陷阱
步骤一：类声明必须整体加导出宏，不能只修饰构造函数或个别方法
class MYLIB_API MyClass {
public:
MyClass();
void doWork();
};
若仅写MYLIB_API MyClass();，则类体内部其他成员仍按默认隐藏处理，链接器无法解析MyClass::doWork引用。
步骤二：模板类不能直接导出——DLL中实例化过的模板函数可导出，但调用方无法使用未在DLL中显式实例化的特化版本。
若需跨DLL使用模板，必须将模板定义（.h内实现）完整暴露给调用方，或在DLL源码中强制实例化所需类型并导出，例如：template class MYLIB_API std::vector<mydata>;</mydata>
【模板类导出必须显式实例化+导出声明，否则调用方编译通过但运行时无符号】
解决C++名称修饰导致的C接口兼容问题
方法1：用extern "C"包裹C风格函数声明
extern "C" {
MYLIB_API int my_c_func(int a, const char* s);
}
这能禁用C++名称修饰，使DLL导出符号名为my_c_func而非类似?my_c_func@@YAHPAHPEBD@Z的乱码，便于C工程或LoadLibrary+GetProcAddress调用。
方法2：对C++类提供纯C封装层
在DLL中定义struct MyHandle;前向声明，所有操作通过MYLIB_API MyHandle* create_handle();等C函数暴露，彻底规避C++ ABI差异和名称修饰问题。
注意：C封装层的结构体不能含虚函数、非POD成员或std::string等C++类型，否则跨语言调用会崩溃。
验证DLL实际导出符号是否符合预期
第一步：用Visual Studio自带工具dumpbin检查
打开x64 Native Tools Command Prompt → 执行：dumpbin /exports mylib.dll
第二步：重点核对输出列表中的“ordinal”、“name”、“bound to”三列，确认关键函数名未被修饰（C接口）或按预期修饰（C++接口），且无缺失。
第三步：若发现符号存在但调用方仍LNK2019，立即检查调用工程是否链接了正确的.lib文件（Debug版必须配Debug .lib，且路径正确），而非仅添加了头文件包含路径。
