Windows首选QueryFullProcessImageName，需PROCESS_QUERY_LIMITED_INFORMATION权限；Linux读/proc/[pid]/exe符号链接；macOS先proc_pidpath后_NSGGetExecutablePath回退。
Windows下用 QueryFullProcessImageName 获取进程路径最可靠
直接调用 QueryFullProcessImageName 是 Windows 上获取进程可执行文件路径的首选方式，它比过时的 GetModuleFileNameEx 更稳定，且不需要额外权限（只要能打开该进程句柄）。注意：必须传入 PROCESS_QUERY_LIMITED_INFORMATION 权限打开进程，而不是旧式 PROCESS_QUERY_INFORMATION（后者在 Vista+ 系统上常因 UAC 失败）。
常见错误是硬编码 PROCESS_QUERY_INFORMATION 导致函数返回 0 且 GetLastError() 为 ERROR_ACCESS_DENIED。正确做法如下：
HANDLE hProc = OpenProcess(PROCESS_QUERY_LIMITED_INFORMATION, FALSE, dwPID);
if (!hProc) return false;
WCHAR szPath[MAX_PATH] = {0};
DWORD dwSize = MAX_PATH;
BOOL bRet = QueryFullProcessImageName(hProc, 0, szPath, &dwSize);
CloseHandle(hProc);
// 注意：bRet 为 TRUE 才表示成功，szPath 是完整路径（如 C:\Program Files\App\app.exe）
补充说明：
-
dwSize必须初始化为缓冲区大小，函数会写入实际长度（不含终止符） - 第2个参数为
0表示获取镜像路径；设为1可获取重定向后的路径（极少用） - 若进程已退出，
OpenProcess会失败，需提前检查
Linux 下读取 /proc/[pid]/exe 符号链接
Linux 没有系统 API 直接返回路径，而是通过读取 /proc/[pid]/exe 这个符号链接来获得。这是最轻量、最通用的方式，不依赖 libprocps 或其他第三方库。
立即学习“C++免费学习笔记（深入）”；
典型陷阱是忽略符号链接可能被破坏或指向 (deleted) —— 这表示对应二进制文件已被删除但进程仍在运行。代码中必须处理 readlink 返回值和 errno：
char path[PATH_MAX] = {0};
snprintf(path, sizeof(path), "/proc/%d/exe", pid);
ssize_t len = readlink(path, buf, sizeof(buf) - 1);
if (len == -1) {
if (errno == ENOENT) /* 进程不存在 */;
else if (errno == EACCES) /* 权限不足，常见于其他用户进程 */;
}
buf[len] = '\0';
// 注意：buf 内容可能是 "(deleted)"，此时路径已失效
关键点：
- 不要用
fopen("/proc/.../exe")—— 它读的是链接目标内容，不是路径字符串 - 普通用户无法读取其他用户进程的
/proc/[pid]/exe，除非有ptrace权限或 CAP_SYS_PTRACE - 容器环境（如 Docker）中，路径可能是相对宿主机的绝对路径，需结合
/proc/[pid]/root判断命名空间上下文
macOS 需组合 proc_pidpath 和 _NSGetExecutablePath 回退逻辑
macOS 不提供类似 Linux 的 procfs，主要靠 libproc 的 proc_pidpath。但它有个严重限制：对 sandboxed 进程（包括绝大多数 GUI 应用）会静默失败，返回 0。
因此不能只依赖一个函数。稳妥做法是先试 proc_pidpath，失败后对当前进程（PID == getpid()）用 _NSGetExecutablePath 回退，其余 PID 则只能返回空或报错：
char path[PROC_PIDPATHINFO_MAXSIZE];
int ret = proc_pidpath(pid, path, sizeof(path));
if (ret <= 0) {
if (pid == getpid()) {
uint32_t size = sizeof(path);
_NSGetExecutablePath(path, &size); // 注意：这个函数不填满 buffer 时会返回 -1 并更新 size
} else {
// 其他进程无可靠方法，尤其 sandboxed 进程
return nullptr;
}
}
注意：
-
proc_pidpath在 macOS 10.15+ 对第三方进程限制更严，即使 root 也常返回 0 -
_NSGetExecutablePath只适用于当前进程，且返回路径可能含./或未解析的符号链接 - 没有等效的“跨用户获取路径”机制，Apple 明确将此列为隐私保护项
跨平台封装要注意权限、生命周期和路径有效性
写跨平台函数时，别指望统一返回“总能拿到”的路径。真实场景中，路径可能因权限、沙箱、进程退出或文件删除而不可用。重点应放在：明确失败原因、提供 fallback 路径（如仅返回进程名）、并避免静默截断。
几个容易被忽略的实际约束：
- Windows 上，64位程序查32位进程（WoW64）时
QueryFullProcessImageName仍可用，但GetModuleFileNameEx会失败 - Linux 下
/proc/[pid]/exe的目标文件可能被chroot或 mount namespace 隔离，readlink返回的路径在调用方命名空间里未必可访问 - 所有平台都需检查进程是否还存活——获取到路径不代表进程仍在运行，后续操作前应再验证
最复杂的其实是语义判断：你真正需要的是“启动时用的路径”，还是“当前磁盘上对应的二进制位置”？前者在进程重命名或移动后就失效了，后者在文件被删后就不存在了。这两个问题没有银弹解法。
