Windows下手动加载DLL最通用可控，需用LoadLibrary+GetProcAddress，注意路径、导出名、调用约定；隐式链接依赖.lib和同名DLL共存；C++类导出须用工厂函数；调试用Process Monitor和Dependencies定位依赖问题。
用 LoadLibrary 和 GetProcAddress 手动加载 DLL
Windows 下最通用、最可控的方式就是手动加载，不依赖编译时链接。它能绕过 LNK2019 未解析外部符号错误，也方便做插件式热加载。
常见错误现象：LoadLibrary 返回 NULL，但没调用 GetLastError() 查原因；或者 GetProcAddress 返回空指针，却直接当函数指针调用导致崩溃。
- 先确保 DLL 路径正确——相对路径是相对于进程当前工作目录，不是 .exe 所在目录；推荐用绝对路径或
GetModuleFileName+ 路径拼接 - 函数名必须和 DLL 导出表里完全一致：C++ 编译的函数默认有名字修饰（mangling），除非用
extern "C"声明，否则要用dumpbin /exports xxx.dll确认真实导出名 - 获取函数指针后，务必用
typedef显式声明类型再强制转换，避免调用约定不匹配（如__cdeclvs__stdcall）引发栈失衡
示例片段：
typedef int (__stdcall *AddFunc)(int, int);
HMODULE hMod = LoadLibrary(L"calc.dll");
if (hMod) {
AddFunc pAdd = (AddFunc)GetProcAddress(hMod, "Add");
if (pAdd) {
int res = pAdd(2, 3); // 安全调用
}
}
用 #pragma comment(lib, "...") 隐式链接时的坑
这种方式看着像静态链接，实际仍需运行时加载 DLL，只是由系统自动完成。但它对开发环境和部署路径极其敏感。
立即学习“C++免费学习笔记（深入）”；
常见错误现象：编译通过、调试时正常，发布后报错 0xc000007b 或 找不到指定模块；或者链接时报 LNK4042 对象被多次指定。
-
.lib文件只是导入库（import library），不包含实现，只含符号转发信息；必须保证同名 DLL 在运行时可被找到（PATH、同目录、AppLocal 等） - 32/64 位严格匹配：用 x64 工具链生成的
.lib不能链接 x86 DLL，反之亦然；dumpbin /headers xxx.lib可查目标架构 - 不要混用隐式链接和手动加载同一 DLL——可能导致 DLL 被多次初始化，全局变量重复构造
处理 C++ 类导出时为什么必须用工厂函数
DLL 里直接导出类（比如 __declspec(dllexport) class Widget）看似方便，但实际几乎不可行：内存布局、虚表偏移、RTTI、异常处理机制在不同编译器或版本间不兼容。
典型表现：构造对象后调用虚函数崩溃；dynamic_cast 失败；析构时释放了错误的堆内存。
- 正确做法是只导出纯 C 风格函数，例如
CreateWidget()和DestroyWidget()，内部 new/delete 全由 DLL 自己管理 - 所有跨 DLL 边界的对象生命周期必须明确归属——谁分配、谁释放，禁止在 EXE 中 delete DLL 分配的对象（或反过来）
- 如果要用智能指针，别传
std::shared_ptr，改用裸指针 + 显式销毁函数，或自定义 deleter 绑定到 DLL 的释放逻辑
调试时 DLL 加载失败怎么快速定位
比起猜路径或权限问题，直接看系统到底做了什么更高效。
常见错误现象：程序静默退出、断点进不去 DLL 初始化代码、LoadLibrary 失败但 GetLastError 返回 0（其实是之前 API 覆盖了错误码）。
- 启用 Windows 事件查看器 → 应用程序日志，筛选“SideBySide”或“Application Error”，常有 DLL 依赖缺失提示
- 用
Process Monitor过滤进程名 + “Path Contains .dll”，观察所有NAME NOT FOUND或PATH NOT FOUND的路径尝试 - 用
Dependencies（新版替代 Dependency Walker）打开 DLL，它会标红缺失的直接依赖（包括 VC++ 运行时、其他 DLL），且支持递归扫描
真正麻烦的永远不是“怎么写”，而是“哪个 DLL 没加载”“它又依赖了谁”“那个依赖为什么没找到”——这三步漏掉任意一环，就只能靠重启加祈祷。
