Windows 下用 EnumProcessModulesEx（配 LIST_MODULES_ALL）配合 OpenProcess 获取模块基地址最可靠；Linux 下解析 /proc/self/maps 中 r-x 权限且含 .so 的行提取十六进制起始地址；二者不可统一封装，需分平台实现。
Windows 下用 EnumProcessModules 获取所有已加载模块基地址
Windows 没有公开 API 直接列出“当前进程加载的所有 DLL”，但 EnumProcessModules 是最可靠的方式——它枚举当前进程的模块句柄，再用 GetModuleInformation 提取基地址（lpBaseOfDll）。注意：必须链接 psapi.lib，且在 Windows 7+ 上推荐用 EnumProcessModulesEx 配合 LIST_MODULES_ALL 标志，否则默认只返回用户模式模块，漏掉某些驱动或伪模块。
常见错误是传入无效的 HANDLE：别用 GetCurrentProcess() 直接传给 EnumProcessModules，它要求句柄具有 PROCESS_QUERY_INFORMATION 和 PROCESS_VM_READ 权限。正确做法是：
HANDLE hProc = OpenProcess(PROCESS_QUERY_INFORMATION | PROCESS_VM_READ, FALSE, GetCurrentProcessId());
如果返回 ERROR_ACCESS_DENIED，说明权限不足（比如被调试器或 UAC 限制），此时只能退回到 EnumProcessModules + 当前进程句柄（部分旧系统允许）。
Linux 下读取 /proc/self/maps 解析 SO 基地址
Linux 没有等价于 Windows 模块枚举的 syscall，标准做法是解析 /proc/self/maps。该文件每行描述一段内存映射，其中以 .so 结尾的路径行，其首列十六进制地址就是该共享库的加载基址（起始地址）。
立即学习“C++免费学习笔记（深入）”；
关键点在于识别“真正加载的 SO”：不能只靠文件名后缀，要过滤掉 [stack]、[heap]、[vdso] 等伪条目；同时注意同一 SO 可能因 MAP_SHARED 出现多次映射（如代码段、数据段分离），只需取第一个可执行（rxp 或 r-xp）的映射行。
示例匹配逻辑（C++ 伪代码）：
std::string line;
while (std::getline(file, line)) {
std::istringstream iss(line);
std::string addr, perms, offset, dev, inode, path;
iss >> addr >> perms >> offset >> dev >> inode >> path;
if (perms.substr(0, 3) == "r-x" && !path.empty() && path.find(".so") != std::string::npos) {
auto dash = addr.find('-');
std::string base = addr.substr(0, dash);
// base 是 16 进制字符串，需 std::stoul(base, nullptr, 16)
}
}
跨平台封装要注意符号可见性与 libc 版本兼容性
想写个统一接口？别直接封装成一个函数。Windows 和 Linux 的数据来源、生命周期、错误语义完全不同：Windows 返回的是稳定句柄，Linux 解析的是瞬时文本快照。更麻烦的是，/proc/self/maps 在容器或某些嵌入式 libc（musl）中行为不一致——musl 默认不挂载 procfs，或者 maps 格式略有差异（如缺失 inode 字段）。
实际工程中建议分两套实现，并加编译期断言：
- Windows：依赖
psapi.h，链接psapi.lib，注意 VS2015+ 默认启用/DELAYLOAD:psapi.dll，若未运行时加载会 crash - Linux：用
std::ifstream读/proc/self/maps，避免用system()或popen()，防止 shell 注入或 fork 失败 - macOS 不适用——它用
_dyld_image_count()+_dyld_get_image_header()，且基地址是 slide 后的地址，需结合_dyld_get_image_vmaddr_slide()
GetModuleHandle(nullptr) 不能替代全量枚举
有人误以为调用 GetModuleHandle(nullptr) 能拿到主模块基址，就类推“遍历所有模块名再逐个调用”——这不可行。Windows 模块名不是全局唯一标识，同名 DLL（如多个版本的 msvcp140.dll）可能共存，GetModuleHandle 只返回第一个匹配句柄；而且很多模块（如通过 LoadLibraryEx 加载的无名模块、延迟加载 DLL）根本没注册名称，查不到。
真正安全的做法只有 EnumProcessModules（Win）或 /proc/self/maps（Linux）这种底层内存视图方式。临时绕过方案（比如仅查已知 DLL）只适用于调试或监控场景，不能用于热更新、hook 或地址校验等强一致性需求。
最易忽略的一点：Linux 下 /proc/self/maps 中的基地址是映射起点，但共享库的 ELF PT_LOAD 段可能有偏移，真实入口点（如 _start）还需解析 ELF header，别把 map 地址直接当 dladdr 返回的 dli_fbase。
