LoadLibrary失败主因是路径错误或字符集不匹配：必须用L"xxx.dll"宽字符字面量，避免ANSI/Unicode混用；相对路径按工作目录而非EXE目录解析，依赖DLL需置于PATH或同目录。
Windows 下用 LoadLibrary 加载 DLL，路径和字符集必须对得上
Windows 上 LoadLibrary 失败最常见的原因是路径不对或 Unicode/ANSI 混用。它默认是宽字符函数（LoadLibraryW），传入 char* 字符串会隐式转码失败，尤其路径含中文或空格时直接返回 NULL。
- 始终用
L"xxx.dll"字面量，或确保字符串是wchar_t*；混用LoadLibraryA要显式声明且不推荐 - 相对路径按当前工作目录解析，不是 EXE 所在目录——要用
GetModuleFileName+PathRemoveFileSpec拼出 DLL 同级路径 - 依赖的其他 DLL（如 MSVCRT、VCRUNTIME）没在 PATH 或同目录时，
LoadLibrary也会静默失败；用Dependency Walker或Process Monitor查加载行为
Linux 下 dlopen 找不到 so 文件，多半是 LD_LIBRARY_PATH 或 rpath 没配好
dlopen("libxxx.so", RTLD_NOW) 返回 NULL 时，dlerror() 通常报 “file not found”，但这不一定是文件真丢了——更可能是动态链接器压根没去那个路径搜。
- 默认只查
/lib、/usr/lib和LD_LIBRARY_PATH中的路径；把 so 放进项目目录后，必须导出：export LD_LIBRARY_PATH=./:$LD_LIBRARY_PATH - 编译时加
-Wl,-rpath,'$ORIGIN'，这样运行时会自动查可执行文件所在目录；$ORIGIN是字面量，不能省引号 - so 文件名要带版本号（如
libxxx.so.1），但dlopen参数写"libxxx.so"也能命中——前提是存在对应软链接；否则得写全名
跨平台封装 LoadLibrary/dlopen 时，函数指针类型必须严格匹配
拿到模块句柄后，用 GetProcAddress（Windows）或 dlsym（Linux）取函数地址，返回的是 void*，强制转成函数指针时，调用约定和参数类型错一个就崩。
windows-auto
下载
Windows 桌面自动化技能，支持鼠标控制（移动/点击/拖拽/滚轮/截图）、键盘输入（文字输入/按键/组合键）、窗口管理（查找/聚焦/最大化/最小化/关闭/移动）、截图并发送文件。提供两种截图方式：Python pyautogui 截图（集成在自动化流程中）和 PowerShell + .NET 零依赖截图（支持区域截图和多显示器）。当用户需要自动化 Windows 桌面操作、控制鼠标键盘、管理窗口、执行 GUI 自动化任务、截图发送文件时使用。
- Windows 上 C++ 成员函数不能直接导出为 C 风格符号；DLL 里导出的必须是
extern "C"函数，且声明与定义的签名完全一致（包括 const、引用、默认参数） - Linux 下
dlsym返回的指针赋给函数指针变量前，必须显式reinterpret_cast；C 风格强转（(func_type)）在某些编译器下会静默忽略调用约定差异 - 示例：假设导出函数
int add(int a, int b)，取地址后应写：auto fn = reinterpret_cast<int>(dlsym(handle, "add"));</int>
卸载时 Windows 的 FreeLibrary 和 Linux 的 dlclose 不是“必须配对”，但资源泄漏有隐蔽风险
多数场景下不调用卸载函数也不会立即出问题，但反复加载/卸载同一库时，Windows 可能残留模块引用计数，Linux 则可能让全局符号表混乱，尤其涉及全局构造函数或 TLS 的库。
立即学习“C++免费学习笔记（深入）”；
- Windows 下
FreeLibrary成功只表示引用计数减一，真正释放要等计数归零；多次LoadLibrary同一路径会复用句柄，所以FreeLibrary次数必须匹配LoadLibrary次数 - Linux 下
dlclose并不保证立即卸载——如果其他已加载的库也依赖它，或符号被缓存，它仍驻留内存；dlclose后再dlopen同名库，可能拿到旧实例 - 调试时可在
FreeLibrary或dlclose后立刻访问已卸载函数指针，Windows 常报 ACCESS_VIOLATION，Linux 多是段错误，但有时靠运气不崩，容易误判逻辑正确
