enumprocessmodules 是 windows 获取模块列表最直接方式，需先用 openprocess 获取带 process_query_information 和 process_vm_read 权限的句柄；首次调用传 null 获取缓冲区大小，二次调用读取模块句柄；再用 k32getmodulefilenameexw（非 getmodulefilenameexw）获取完整路径。
Windows平台用 EnumProcessModules 获取模块列表
在 Windows 上，EnumProcessModules 是最直接的方式，但它需要先获得目标进程的句柄（且需 PROCESS_QUERY_INFORMATION 和 PROCESS_VM_READ 权限）。常见错误是权限不足导致调用失败并返回 0 —— 此时 GetLastError() 通常为 ERROR_ACCESS_DENIED。
实操要点：
- 用
OpenProcess打开目标进程，注意传入正确的访问标志，例如PROCESS_QUERY_INFORMATION | PROCESS_VM_READ -
EnumProcessModules第一次调用需传入NULL缓冲区来获取所需缓冲区大小（单位是字节），第二次才真正读取模块句柄数组 - 对每个模块句柄调用
GetModuleFileNameExW（推荐宽字符版）获取完整路径；GetModuleBaseNameW只返回文件名（不含路径） - 注意：
GetModuleFileNameExW在 Windows 10 1903+ 推荐改用GetModuleFileNameExW的替代函数K32GetModuleFileNameExW（需链接psapi.lib），否则某些系统上可能返回空字符串
Linux 下用 /proc/[pid]/maps 和 /proc/[pid]/exe
Linux 没有等价于 Windows 模块枚举的 API，但可通过解析 /proc/[pid]/maps 提取映射的共享库路径。该文件每行描述一段内存映射，其中以 <code>.so 结尾或含 /lib、/usr/lib 路径的行大概率是加载的模块。
实操要点：
- 打开
/proc/[pid]/maps后逐行读取，用空格分割字段，第6列（从0开始数）是路径；若为空则跳过（如 [heap]、[stack]） - 同一模块可能被多次映射（如不同内存属性段），需用
std::set<:string></:string>去重 -
/proc/[pid]/exe是符号链接，可读取其指向获取主程序路径，但不属于“加载模块”，需单独处理 - 注意权限：非 root 或非同用户进程，
/proc/[pid]/maps可能不可读（Permission denied），此时只能读自己进程（getpid()）
C++跨平台封装要注意的兼容点
没有标准 C++ 接口能统一获取模块列表，强行抽象容易掩盖关键差异。比如 Windows 返回的是 HMODULE（本质是地址），Linux 则依赖文本解析 —— 二者语义不同，不能简单用同一容器存“模块名”。
建议做法：
- 避免写“跨平台通用模块枚举函数”，按平台分文件实现（
enum_modules_win.cpp/enum_modules_linux.cpp） - 返回类型统一用
std::vector<:string></:string>（存路径），但明确文档注明：Windows 下是完整路径，Linux 下可能缺失部分动态链接器隐式加载的模块（如ld-linux.so不出现在 maps 中） - 不要依赖
dladdr：它只查调用栈中符号所在模块，无法枚举全部已加载模块
常见误判：把内存映射当模块
尤其在 Linux 上，/proc/[pid]/maps 里大量条目是匿名映射（[anon]）、堆、栈、VDSO，甚至用户态分配的大页 —— 它们不是“模块”。仅靠是否有文件路径不足以判断是否为动态库。
更稳妥的过滤逻辑：
- 路径存在且以
.so结尾 - 或路径含
lib子串且扩展名是.so、.dll（兼容交叉编译环境） - 排除
/dev/zero、[heap]、[stack]、[vdso]、[vvar]等伪路径 - 实际生产中建议加一层
access(path.c_str(), F_OK)验证路径可访问，避免挂载点失效导致的脏数据
模块名不是文件名，而是加载进内存的那个实体 —— 有些模块会被 LD_PRELOAD 注入却不在 maps 的常规位置，这种场景必须结合 lsof -p [pid] 或 gdb attach 辅助验证，代码层面很难全覆盖。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
