C++如何获取当前程序运行路径 _ Windows与Linux跨平台实现【干货】

C++如何获取当前程序运行路径：Windows与Linux跨平台实现【干货】

Windows 用 GetModuleFileNameA 获取可执行文件绝对路径，Linux 用 readlink("/proc/self/exe") 读取符号链接，两者均需截断至目录部分；禁用 getcwd() 和不可靠的 argv[0]。

想在Windows和Linux上获取当前程序自己的运行路径？这事儿看似简单，却有个经典的“坑”：很多人下意识会用getcwd()，结果拿到的却是进程启动时的工作目录，跟程序文件实际躺在哪个文件夹完全不是一回事。正确的思路是，直接去问操作系统：“我这个可执行文件自己到底在哪？”——这就需要调用不同的系统API来读取自身的完整路径，然后再手动把文件名部分“砍掉”，只保留目录。

Windows 下用 GetModuleFileNameA 获取 exe 路径

在Windows的世界里，这事儿有官方的“标准答案”：GetModuleFileNameA这个API（或者它的宽字符版本GetModuleFileNameW）就是干这个的。你只需要给它传入一个NULL或者HMODULE(0)，它就会老老实实地把当前进程主模块（也就是你的.exe文件）的完整路径塞到你提供的缓冲区里。

• 首先，别忘了包含头文件。
• 缓冲区大小怎么定？保险起见，至少准备MAX_PATH（260）个字符。更稳妥的做法是直接用MAX_PATH + 1，或者干脆动态分配内存。
• 调用后，返回值是实际写入的字符长度。如果返回0，那就说明出错了，赶紧用GetLastError()查查原因。
• 拿到的是一个完整的绝对路径，包含盘符和.exe后缀。你需要自己动手，用find_last_of('\')找到最后一个反斜杠的位置，然后把后面的部分截掉，才能得到纯目录。

char path[MAX_PATH];
if (GetModuleFileNameA(NULL, path, MAX_PATH) == 0) {
    // 处理错误
}
std::string exe_dir = std::string(path, path + strlen(path));
size_t last_sep = exe_dir.find_last_of('\');
if (last_sep != std::string::npos) {
    exe_dir = exe_dir.substr(0, last_sep);
}

Linux 下用 /proc/self/exe 符号链接解析

到了Linux这边，情况略有不同。系统没有提供一个完全等价的直接API，但别担心，Linux有它自己的“魔法文件系统”——/proc。其中，/proc/self/exe这个神奇的符号链接，指向的就是当前可执行文件的绝对路径。这可以说是最通用、最直接的方法了，它不依赖argv[0]，而且能正确处理符号链接启动的情况。

• 需要包含的头文件是和。
• 使用readlink("/proc/self/exe", buf, sizeof(buf)-1)来读取链接目标。注意，返回值是实际读取的字节数，系统不会自动给你加上字符串结束符。
• 如果返回-1或者0，说明环境可能有问题（比如某些容器里procfs不可用，或者chroot环境），这时候就需要准备降级方案了。
• 和Windows一样，得到的路径可能带.out后缀，也可能没有。同样需要用find_last_of('/')找到最后一个斜杠并截断，才能得到目录。

char buf[PATH_MAX];
ssize_t len = readlink("/proc/self/exe", buf, sizeof(buf)-1);
if (len == -1 || len == 0) {
    // fallback needed
}
buf[len] = '';
std::string exe_dir(buf);
size_t last_sep = exe_dir.find_last_of('/');
if (last_sep != std::string::npos) {
    exe_dir = exe_dir.substr(0, last_sep);
}

跨平台封装时注意 argv[0] 的陷阱

说到降级方案，很多人第一个想到的就是argv[0]。但这里必须敲个黑板：argv[0]是个“大坑”，极其不可靠。它可能只是一个相对路径（比如"./myapp"），可能是个空字符串，甚至可能被调用者随意篡改，根本不指向真实的可执行文件（想想shell alias、符号链接，或者LD_PRELOAD注入的场景）。因此，它只应该作为最后的手段，也就是当/proc/self/exe和GetModuleFileName都宣告失败时，才尝试用它。而且，用之前必须经过规范化处理：Linux下用realpath()，Windows下用GetFullPathName。

立即学习“C++免费学习笔记（深入）”；

• 在fork()加exec()之后，argv[0]很可能已经丢失了原始的路径信息。
• Linux下，realpath(argv[0], NULL)会动态分配内存，记得用free()释放。
• Windows下，GetFullPathNameA(argv[0], ...)不会解析符号链接，准确性远不如GetModuleFileName。
• 任何基于argv[0]的逻辑，都应该放在#else这样的备选分支里，并且明确标注为“尽力而为（best-effort）”，让使用者心里有数。

路径分隔符与 Unicode 兼容性问题

好不容易拿到路径字符串了，处理的时候也别大意。别在代码里硬编码'\'或者'/'来分割路径——虽然Windows API返回的是反斜杠，Linux返回的是正斜杠。如果项目能用C++17，那恭喜你，直接用std::filesystem::path，它能自动处理这些平台差异。如果还用不了，那至少统一用std::string::find_last_of("\/")来兼容两种分隔符。

• 如果用了Windows的宽字符版本GetModuleFileNameW，得到的是UTF-16编码的字符串。为了和Linux的UTF-8路径行为保持一致，需要转换成UTF-8，推荐使用WideCharToMultiByte(CP_UTF8, ...)。
• 再次强调，别用std::filesystem::current_path()来偷懒，它返回的还是那个会变的“工作目录”。
• 如果你的程序是通过符号链接启动的，Linux的/proc/self/exe默认会返回符号链接指向的目标路径。如果你非要拿到原始的链接路径本身，需要读两次readlink（不过这种需求很少见）。

说到底，要实现一个真正健壮的跨平台路径获取，核心原则就两条：在Windows上，死守GetModuleFileName；在Linux上，死守/proc/self/exe。除此之外的任何路径来源，都只能当作备胎，而且必须配上清晰的降级标记和错误日志。别相信什么“一个函数走天下”的神话，底层系统的差异就明明白白摆在那里，尊重差异，代码才能可靠。