最稳妥方式是windows调用getmodulefilename(null)、linux用readlink("/proc/self/exe")、macos用_nsgetexecutablepath后接realpath()归一化，均需检查返回值、缓冲区大小及路径有效性。

Windows 下用 GetModuleFileName 获取当前程序路径最稳妥的方式

直接调用 GetModuleFileName 时传 NULL（或 0）作为模块句柄，能拿到当前可执行文件的完整绝对路径，这是 Windows 平台最可靠的做法。它不依赖当前工作目录，也不受快捷方式启动影响。

• GetModuleFileName 返回的是宽字符（wchar_t）路径，如果项目没开 Unicode，得用 GetModuleFileNameA 或手动转换
• 缓冲区必须足够大，推荐固定分配 MAX_PATH（260）字节；超过此长度可能被截断，但现代 Windows 支持长路径，可用 GetLongPathName 补救
• 返回值是实际写入的字符数（不含结尾 \0），不是布尔成功标志——返回 0 才代表失败，记得检查

Linux/macOS 怎么办？readlink("/proc/self/exe") 是事实标准

Linux 下没有等价的 API，readlink("/proc/self/exe") 是唯一稳定方案。macOS 虽无 /proc，但可用 _NSGetExecutablePath 替代，不过它不保证返回绝对路径，常带 ./ 前缀，需额外处理。

• readlink 返回的是符号链接指向的真实路径，对硬链接、重命名后的可执行文件也准确
• 缓冲区大小不能只给 PATH_MAX 就完事——readlink 不自动补 \0，必须手动置零或预留多一字节
• macOS 的 _NSGetExecutablePath 在沙盒环境可能失败，且路径可能相对，建议调用 realpath() 归一化

跨平台封装要注意的三个坑

写个 get_executable_path() 函数时，最容易在路径合法性、编码、内存管理上翻车。

C++ Code Review Master

组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。

下载

• 不要假设返回路径一定以驱动器盘符（Windows）或 /（Unix）开头——比如某些调试器启动时路径可能是空或无效，得判空+失败重试
• C++ 字符串类型选 std::string 还是 std::wstring？Windows 宽字符路径含中文不会乱码，但跨平台库（如 std::filesystem）在 C++17 后统一用 std::string + UTF-8 编码，中间转换容易出错
• 别把 GetModuleFileName 的输出直接塞进 std::string——宽字符转 UTF-8 必须用 WideCharToMultiByte(CP_UTF8, ...)，硬 cast 会丢数据

std::filesystem::canonical("argv[0]") 为什么不可靠

有人想走“捷径”：用 argv[0] 加 std::filesystem::canonical 推导路径。这在多数情况看似可行，但实际场景中非常脆弱。

• argv[0] 可能只是程序名（如 "myapp"），不含路径，canonical 会在 $PATH 中搜索，结果完全不可控
• 如果程序是通过软链接启动，argv[0] 是链接路径，canonical 返回的是链接目标，而非真正被加载的二进制位置
• Windows 下 argv[0] 可能被 shell 截断或包含引号，std::filesystem 解析失败率高，错误码还不好捕获

真正的程序路径，只能从系统加载器那里问——Windows 问 GetModuleFileName，Linux 问 /proc/self/exe，其他路都是绕远又易错。

C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！