最可靠方式是读取 /proc/self/maps 并过滤 r-xp 且含 .so 的行，再用 realpath() 标准化路径；windows 下必须用 enumprocessmodules + getmodulefilenameexa 获取模块全路径。
Linux 下用 /proc/self/maps 解析已加载的 .so 路径最可靠
Linux 没有标准 API 直接枚举所有已加载的共享库路径，dl_iterate_phdr 只能拿到 ELF 段信息，不包含完整路径；dladdr 依赖符号地址，对无符号的库（如 libpthread.so.0）可能返回空。真正稳定的方式是读取 /proc/self/maps 并过滤出映射类型为 r-xp 且含 .so 的行，再结合 /proc/self/map_files/ 或 readlink 还原绝对路径。
实操建议：
- 逐行读
/proc/self/maps，匹配正则^([0-9a-f]+)-([0-9a-f]+) [rwxp-]{4} [0-9a-f]+ [0-9a-f]+:[0-9a-f]+ [0-9]+ +(.+)$，第三列含.so且非方括号包裹（如[vdso]）才保留 - 对匹配到的路径字段（如
/lib/x86_64-linux-gnu/libc.so.6），用realpath()标准化，避免软链接干扰 - 注意：某些库可能以匿名方式映射（路径为空），或路径被
LD_LIBRARY_PATH动态拼接，此时需 fallback 到dl_iterate_phdr辅助验证
Windows 下必须用 EnumProcessModules + GetModuleFileNameExA
Windows 没有类似 /proc 的虚拟文件系统，只能靠 PSAPI。关键点在于：EnumProcessModules 返回的是模块句柄列表，但不带路径；必须对每个句柄调用 GetModuleFileNameExA 才能得到全路径。直接用 GetModuleFileNameA 只能拿到当前进程主模块（exe）路径，完全无效。
常见错误现象：
- 忘记链接
psapi.lib，导致链接失败或运行时GetModuleFileNameExA返回 0 - 未用
OpenProcess(PROCESS_QUERY_INFORMATION | PROCESS_VM_READ, FALSE, GetCurrentProcessId())获取有效句柄，导致权限不足返回空字符串 - 缓冲区大小传
MAX_PATH但实际路径超长（尤其含长符号链接或网络路径），应改用GetModuleFileNameExW+wchar_t避免截断
C++ 跨平台封装要注意符号可见性与链接时机
如果写成通用函数（如 std::vector<:string> getLoadedLibraries()</:string>），Linux 版本必须在编译时定义 _GNU_SOURCE（否则 getline 不可用），Windows 版本需在头文件里 #ifdef _WIN32 包裹 PSAPI 头和 lib 引用。更隐蔽的问题是：某些库（如 libdl.so）在 dlopen 后才出现在 maps 中，但你的函数若在 main() 开头就调用，会漏掉延迟加载的库。
使用场景决定策略：
- 调试用途：可接受少量延迟，直接在目标函数前后各采样一次，比对新增项
- 插件热加载检测：必须在
dlopen/LoadLibrary返回后立刻调用，否则无法捕获 - 静态链接的 CRT 库（如
libcmt.lib）不会出现在列表中——它根本不是独立 .so/.dll，这点容易误判为 bug
Python ctypes 或 GDB 调试时别依赖 C++ 函数结果
很多用户想用 Python 脚本调用自己写的 C++ 函数来获取 so 列表，但实际会遇到问题：ctypes.CDLL("./libfoo.so") 本身就会触发新的 dlopen，改变 /proc/self/maps 状态；GDB 下执行 info sharedlibrary 显示的是调试器视角的加载状态，和进程真实内存映射可能不同步（尤其多线程场景下）。
更稳妥的做法：
- Linux 下直接 shell 命令：
cat /proc/$(pidof your_program)/maps | awk '$6 ~ /\.so$/ {print $6}' | sort -u，绕过任何代码层干扰 - Windows 下用 PowerShell：
Get-Process -Id $PID | Select-Object -ExpandProperty Modules | ForEach-Object {$_.FileName} - 若必须嵌入 C++，记得在函数开头加
fflush(nullptr)和std::this_thread::yield()，减少因输出缓冲或调度导致的映射状态滞后
路径解析的边界情况远比想象中多：容器内 PID namespace、chroot 环境下的路径不可达、ASLR 导致的地址段重叠判断……真要覆盖全部，得放弃“全路径”这个目标，先确认你到底需要路径做啥——是日志归档、依赖检查，还是反注入检测？目的不同，方案差很远。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
