Linux下最可靠方式是直接读取/proc/self/maps解析.so基址：逐行匹配库名，提取r-xp权限段的十六进制起始地址；该文件由内核实时维护，反映真实映射状态，不受LD_PRELOAD等干扰。
Linux下用 /proc/self/maps 解析动态库路径最可靠
直接读取 /proc/self/maps 是 Linux 上获取当前进程已加载动态库全路径的最底层、最准确方式。它不依赖符号表或调试信息，也不受 LD_PRELOAD 或 RTLD_NODELETE 等运行时行为干扰，能反映内核实际维护的映射状态。
关键点在于：每行中以 .so 结尾且权限含 x（可执行）或含 .so 字样在路径段的映射行，基本对应一个加载的动态库；起始地址后的路径字段即为全路径（可能为空，需结合 /proc/self/exe 和 ldd 补充）。
- 用
std::ifstream逐行读取/proc/self/maps，跳过无路径的行（如[heap]、[stack]） - 对每行用空格分割，取最后一个非空字段作为路径候选；若该字段含
.so且不是[vdso]或[vvar]等伪映射，则保留 - 路径为绝对路径则直接使用；若为相对路径（极少见）或为空，需 fallback 到
dladdr()+ 符号查询，或调用ldd /proc/self/exe | grep '=>'（不推荐，开销大）
macOS 必须用 _dyld_image_count() + _dyld_get_image_name()
macOS 没有 /proc 文件系统，也无法通过 dl_iterate_phdr() 获取全部镜像（它只遍历 ELF-style 的 program header，而 dyld 加载的是 Mach-O 镜像）。唯一可移植且稳定的方式是 dyld 提供的私有 C API。
注意：_dyld_image_count() 返回的是当前所有已加载镜像数（包括主程序、dylib、bundle），_dyld_get_image_name(i) 返回第 i 个镜像的路径字符串——这个字符串始终是全路径，且生命周期与进程一致，无需 strdup。
立即学习“C++免费学习笔记（深入）”；
- 需包含
<dlfcn.h>和<mach-o/dyld.h>（后者非标准头，但 macOS SDK 提供） - 循环从
i = 0到_dyld_image_count() - 1，调用_dyld_get_image_name(i) - 过滤掉以
/usr/lib/system/开头的系统库（如libsystem_c.dylib）可选，但不应排除@rpath/或@executable_path/开头的路径——它们在运行时已被 dyld 展开为真实全路径
dl_iterate_phdr() 在 Linux 上只能看到部分动态库
dl_iterate_phdr() 看似是标准接口，但它只遍历“参与链接过程”的 ELF 共享对象，对 dlopen() 动态打开、未关联到全局符号表、或用 RTLD_LOCAL 标志加载的库，很可能不出现。更严重的是：它完全看不到通过 LD_PRELOAD 注入的库（它们被插入在 _DYNAMIC 之前，不在 phdr 链表中）。
实测中，LD_PRELOAD=libfoo.so ./a.out 后，dl_iterate_phdr() 回调里根本收不到 libfoo.so 的 dl_phdr_info。
- 仅适合快速枚举主程序依赖链上的显式链接库（如
libstdc++.so、libc.so） - 回调函数中必须检查
info->dlpi_name是否非空且非""；空值表示该段无文件名（如 vDSO） - 不要假设
info->dlpi_addr是库加载基址——Mach-O 和某些 PIE 构建的 ELF 中它可能是 0
Windows 上要用 EnumProcessModules() + GetModuleFileNameEx()
Windows 没有“动态库路径”概念，只有模块（HMODULE）；每个模块对应一个加载进进程地址空间的 PE 映像（DLL 或 EXE）。要拿到全路径，必须先枚举所有模块句柄，再逐个查文件名。
关键限制：需要 PROCESS_QUERY_INFORMATION 权限，且默认情况下子进程可能无此权限；若目标进程是自己（GetCurrentProcess()），则始终可用。
- 调用
EnumProcessModules(GetCurrentProcess(), hMods, sizeof(hMods), &cbNeeded)获取模块句柄数组 - 对每个
HMODULE调用GetModuleFileNameEx(GetCurrentProcess(), hmod, szPath, MAX_PATH)，而非GetModuleFileName()（后者只对当前模块或已知模块有效） - 结果路径是 Unicode 宽字符，需用
wchar_t缓冲区；若需 UTF-8，用WideCharToMultiByte(CP_UTF8, ...) - 注意过滤掉
ntdll.dll、kernel32.dll等系统模块——它们路径虽全，但通常不是用户关心的“加载的动态库”
真正难处理的是跨平台抽象：Linux 的 /proc/self/maps 行为和 macOS 的 dyld 镜像索引语义完全不同，没有统一的“加载库列表”定义。哪怕同是 Linux，容器环境里 /proc/self/maps 的路径可能被挂载覆盖，而 readlink("/proc/self/exe") 又未必指向原始二进制——这些细节不手动验证，很容易在某个部署环境下静默失效。
