RAII封装LoadLibrary/FreeLibrary首选std::unique_ptr配自定义删除器，确保HMODULE生命周期与对象严格绑定；禁用shared_ptr避免引用计数脱节导致提前卸载；GetProcAddress返回值须强类型转换并判空。
如何用 RAII 封装 LoadLibrary 和 FreeLibrary
RAII 的核心不是“写个类”，而是让 HMODULE 的生命周期严格绑定到对象生存期。C++11 以后，std::unique_ptr 配合自定义删除器是最轻量、最安全的方式，比手写构造/析构更难出错。
常见错误是把 FreeLibrary 放在析构函数里却没检查 m_hModule 是否为 NULL，或忘记在移动后将原对象置空，导致二次释放。正确做法是交由 std::unique_ptr 管理：
- 定义删除器：
struct LibDeleter { void operator()(HMODULE h) const noexcept { if (h) FreeLibrary(h); } }; - 成员变量声明为：
std::unique_ptr<void libdeleter> m_lib;</void> - 加载时用
LoadLibrary返回值构造：m_lib.reset(LoadLibrary(L"xxx.dll")); - 无需手动析构，移动语义天然支持（
std::unique_ptr已实现）
为什么不用 std::shared_ptr？DLL 句柄能共享吗
不能。Windows DLL 句柄本身支持引用计数（LoadLibrary 多次调用返回同一句柄，FreeLibrary 每次只减一），但多个 std::shared_ptr 共享同一 HMODULE 并不等价于多一次 LoadLibrary —— 它们共用一个引用计数，而 DLL 的实际引用计数由系统维护，二者脱节。一旦某个 shared_ptr 析构触发 FreeLibrary，可能提前卸载 DLL，导致其余持有者调用 GetProcAddress 失败。
所以必须用 std::unique_ptr 强制独占语义，或自己封装引用计数（极少必要）。
立即学习“C++免费学习笔记（深入）”；
GetProcAddress 返回的函数指针怎么安全存取
直接存 FARPROC 不安全：类型擦除后无法做静态检查，调用时容易因参数/调用约定不匹配崩溃（尤其 __stdcall vs __cdecl）。应为每个导出函数定义强类型别名，并用模板封装获取逻辑：
- 例如导出函数
int add(int a, int b)，定义：using AddFunc = int(__cdecl*)(int, int); - 封装获取方法：
template<typename t> T get_proc(const char* name) { return reinterpret_cast<t>(GetProcAddress(m_lib.get(), name)); }</t></typename> - 使用：
auto add = lib.get_proc<addfunc>("add"); if (add) result = add(1, 2);</addfunc> - 注意：
GetProcAddress返回nullptr表示未找到，必须判空；函数签名必须与 DLL 中完全一致（包括调用约定）
加载失败时的错误诊断和兼容性处理
LoadLibrary 失败不等于 DLL 不存在——可能是依赖缺失、位数不匹配（x86 DLL 加载到 x64 进程）、路径错误或 manifest 冲突。不能只靠 GetLastError() 判断，要结合场景排查：
- 用
GetLastError()获取码后，调用FormatMessage转成可读字符串（注意加FORMAT_MESSAGE_FROM_SYSTEM） - 优先用绝对路径加载，避免当前工作目录干扰；若用相对路径，确认
SetCurrentDirectory未被意外修改 - 调试时可用
Dependencies（新版替代 Dependency Walker）查看 DLL 依赖树和缺失项 - Release 版本建议禁用
LOAD_WITH_ALTERED_SEARCH_PATH，防止 DLL 劫持风险
真正麻烦的是隐式依赖的 CRT 或 VC++ 运行时版本不一致——这类问题不会报错，但函数调用中途崩溃，需确保目标 DLL 编译时用的运行时与主程序兼容（推荐静态链接 CRT 或统一安装对应 redist）。
