Linux下用dladdr通过本库内函数或变量地址获取共享库路径，macOS需用_dyld_get_image_name遍历镜像，Windows则用GetModuleHandleEx+GetModuleFileName；三者均需正确传入本库有效地址并注意符号可见性与初始化时机。
Linux 下用 dladdr 获取调用者所在共享库的路径
如果你在某个动态库（比如 libfoo.so）里想知道自己被加载到哪了，dladdr 是最直接的办法。它不查进程全局路径，而是根据一个地址反查所属的映射模块——所以关键是要传入一个「本库内有效的地址」，比如函数地址或全局变量地址。
常见错误是传 nullptr 或随便取的栈地址，结果返回空或指向 libc；也有人误以为它能列出所有已加载的 so 路径，其实不能。
- 必须链接
-ldl，否则链接失败 - 传入地址建议用当前共享库里的符号，例如：
&some_global_var或reinterpret_cast<void*>(&my_func) -
Dl_info结构体中dli_fname字段才是完整路径，可能为绝对路径，也可能为相对路径（取决于加载方式）
#include <dlfcn.h>
#include <iostream>
std::string get_self_path() {
Dl_info info;
if (dladdr(reinterpret_cast<void*>(&get_self_path), &info)) {
return info.dli_fname ? info.dli_fname : "";
}
return "";
}
macOS 下用 _NSGetExecutablePath 不适用，得用 _dyld_get_image_name
_NSGetExecutablePath 只返回主程序路径，对动态库无效。真正能拿到当前 so/dylib 路径的是 _dyld_get_image_name 配合遍历镜像列表——但注意：它返回的是加载时记录的路径字符串，不是实时解析后的绝对路径，且索引需匹配当前镜像序号。
容易踩的坑是硬编码索引（比如总用 0），或者没检查返回值是否为空指针；另外 dyld 镜像列表在运行时可能变化（如 dlopen 新库），所以应尽快缓存。
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 需包含
<dlfcn.h>和<mach-o/dyld.h> - 用
_dyld_image_count()获取总数，再循环调用_dyld_get_image_name(i) - 怎么定位「自己」？通常靠比较
_dyld_get_image_header(i)和当前函数地址所在的段，或在库初始化时（如__attribute__((constructor))）记录自身地址再查表
Windows 下没有等价 dladdr，得靠 GetModuleHandleEx + GetModuleFileName
Windows 的 HMODULE 本质是模块基址，但你无法直接从任意函数指针推出其所属模块——除非你先拿到该函数所在模块的句柄。所以标准做法是：用 GetModuleHandleEx 带 GET_MODULE_HANDLE_EX_FLAG_FROM_ADDRESS 标志，传入本库内函数地址，获取句柄，再调 GetModuleFileName。
失败常见于没开这个 flag、传了内联函数地址（被优化成跳转，地址落在别的模块）、或模块已被卸载（但一般不会在自己代码里发生）。
- 必须定义
WIN32_LEAN_AND_MEAN并链接kernel32.lib - 函数地址不能是静态内联或编译器优化掉的符号；建议显式声明为
extern "C"防 name mangling -
GetModuleFileName返回的可能是短路径（8.3 格式），如需长路径需额外调GetLongPathName
#include <windows.h>
#include <string>
std::string get_self_dll_path() {
HMODULE hMod = nullptr;
if (GetModuleHandleEx(GET_MODULE_HANDLE_EX_FLAG_FROM_ADDRESS |
GET_MODULE_HANDLE_EX_FLAG_UNCHANGED_REFCOUNT,
reinterpret_cast<LPCVOID>(&get_self_dll_path),
&hMod)) {
wchar_t buf[MAX_PATH];
if (GetModuleFileName(hMod, buf, MAX_PATH) > 0) {
return std::string(buf, buf + wcslen(buf));
}
}
return "";
}
跨平台封装要注意符号可见性与初始化时机
写个统一接口时，别只顾路径逻辑，忘了平台差异背后的真实约束：Linux/macOS 的 dladdr/_dyld_get_image_name 依赖符号未被 strip，而 Windows 的 GetModuleHandleEx 在 DLL_PROCESS_ATTACH 之后才稳定可用。如果在全局对象构造函数里就调用，某些平台可能失败。
另一个隐性问题：C++11 以后 inline 变量和 constexpr 函数可能被优化进调用者模块，导致地址归属判断出错。最稳妥的是用一个显式导出的非内联函数作为锚点。
- Linux：确保编译时没加
-fvisibility=hidden（或至少该函数设为default） - Windows：DLL 导出表里要包含锚点函数，否则
GetModuleHandleEx找不到所属模块 - 所有平台都建议加一次缓存，避免重复调用系统 API 影响性能
路径本身可能带符号链接，真实加载位置和字符串显示不一致——真要校验文件存在性，得用 realpath（Linux/macOS）或 GetFinalPathNameByHandle（Windows）进一步解析。
