__declspec(dllexport)不能只写在头文件里，因为编译器需在dll构建时即确定导出符号，而头文件仅提供声明、不参与链接；若实现函数未带该修饰，链接器不会将其加入导出表。
导出函数时为什么__declspec(dllexport)不能只写在头文件里
因为编译器需要在生成DLL时就确定哪些符号要放进导出表，而头文件被包含时只是声明，不参与DLL模块的链接阶段。如果只在头文件里加__declspec(dllexport)，而源文件中实现函数时没带这个修饰，链接器根本不会把它当导出符号处理。
正确做法是：在DLL工程中定义宏控制导出/导入，比如：
#ifdef BUILDING_MYDLL #define MYDLL_API __declspec(dllexport) #else #define MYDLL_API __declspec(dllimport) #endif
然后在函数声明前加上该宏：
extern "C" MYDLL_API int add(int a, int b);
同时确保BUILDING_MYDLL只在DLL项目编译时定义（如在项目属性 → C/C++ → 预处理器 → 预处理器定义中添加）。
- 不加
extern "C"会导致C++名字修饰（mangling），调用方必须用修饰后的名字，极难调试 - 如果导出的是类，需整个类加
MYDLL_API，且注意虚函数表、静态成员等跨DLL边界可能出问题 - 使用
dumpbin /exports mydll.dll验证导出函数是否真的出现在导出表里
用.def文件导出函数有哪些实际好处
它绕过编译器修饰规则，能精确控制导出名、序号，还能导出C++重载函数或避免__declspec宏污染头文件。但缺点也很明显：维护成本高，新增函数必须手动更新.def，且无法导出内联函数或模板实例。
一个最小可用的mydll.def长这样：
LIBRARY mydll
EXPORTS
add @1
subtract @2
注意：@1是序号，不是必须的；没有序号也能导出，但加了序号可提升加载速度（跳过名字查找）。
-
.def文件需在项目属性 → 链接器 → 输入 → 模块定义文件中指定路径 - 若函数名含C++修饰（比如
add@8），.def里必须写修饰后的名字，否则导出失败 - 导出序号一旦发布就不能改，否则调用方按序号加载会失败——这点常被忽略
调用DLL时LoadLibrary成功但GetProcAddress返回NULL怎么办
最常见原因是函数名不匹配：C++编译后名字被修饰，而GetProcAddress传的是原始名。比如声明为int add(int, int)，实际导出名可能是?add@@YAHHH@Z（MSVC x64）或_add@8（x86）。
- 用
dumpbin /exports mydll.dll看真实导出名，再传给GetProcAddress - 加
extern "C"并用__declspec(dllexport)是最稳妥解法，导出名为纯add - 如果DLL是Unicode构建的，确保调用方也用Unicode字符集，否则
GetProcAddress可能因宽窄字符差异找不到符号 - 检查函数是否真在导出表里——有些函数虽声明了
dllexport，但未定义或被#ifdef条件编译掉了
C++ DLL里导出函数能否直接返回std::string或std::vector
不能安全地跨DLL边界返回。因为不同DLL可能链接不同版本的CRT（如/MTd vs /MD），导致内存分配器不一致，调用方释放时崩溃。
可行方案只有两种：
- 返回原始指针+长度（如
const char*+size_t），由DLL内部管理内存，提供配套的free_string函数 - 用COM风格接口或抽象基类（纯虚函数），把对象生命周期完全交给DLL管理
例如导出：
extern "C" MYDLL_API const char* get_message(); extern "C" MYDLL_API void free_message(const char* ptr);
调用方必须严格配对调用free_message，不能用delete[]或free。
这是最容易被低估的兼容性雷区——表面能跑，压力测试或换编译器后立刻崩。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
