argv[0]不能直接当路径用，因其可能是相对路径、绝对路径、符号链接或仅程序名；应优先用readlink("/proc/self/exe")（linux）、_nsgetexecutablepath()（macos）或getmodulefilenamea()（windows），并统一canonical处理。
![c++如何实现跨平台获取可执行文件路径？（argv[0]增强解析）](https://img.php.cn/upload/article/001/431/639/177148913462651.jpg)
为什么 argv[0] 不能直接当路径用
因为 argv[0] 是进程启动时传入的“程序名”，它可能是相对路径、绝对路径、符号链接、甚至只是个名字（比如从 $PATH 查到的）。Linux 下执行 ./a.out、a.out 或 /usr/local/bin/myapp，argv[0] 值完全不同；Windows 下还可能带引号或空格。直接 std::filesystem::absolute(argv[0]) 会失败或指向错误位置。
readlink("/proc/self/exe") 在 Linux/macOS 上怎么安全读取
Linux 用 /proc/self/exe（符号链接）、macOS 用 _NSGetExecutablePath()，两者都比解析 argv[0] 可靠得多。但要注意缓冲区大小、权限、符号链接未解引用等问题。
- Linux：用
readlink()配合足够大的缓冲区（建议 4096 字节），失败后 fallback 到argv[0]；不要忘了nullptr终止和std::filesystem::canonical() - macOS：调用
_NSGetExecutablePath(char*, uint32_t*)，首次传nullptr获取所需长度，再分配内存重试；返回路径是真实路径，但可能含../，建议过一遍std::filesystem::weakly_canonical() - 两者都要检查返回值：
readlink()返回 -1 表示失败；_NSGetExecutablePath()返回非零表示缓冲区不足
Windows 下如何用 GetModuleFileNameA() 获取真实路径
Windows 没有 /proc，必须用 Win32 API。GetModuleFileNameA(NULL, ...) 能拿到当前模块（即主可执行文件）的完整路径，但它返回的是多字节字符串，且可能含驱动器号大写、短文件名（8.3 格式）等干扰项。
- 务必用
GetModuleFileNameA()而不是GetModuleHandleA()+GetModuleFileNameA()组合——前者更直接可靠 - 缓冲区至少设为
MAX_PATH（260），但现代路径可能超长，建议用GetModuleFileNameW()+std::wstring避免编码截断 - 返回路径不一定是规范形式（比如
C:\PROGRA~1\...），需要调用GetLongPathNameW()解析成真实路径 - 注意：如果程序被硬链接或通过快捷方式启动，该 API 仍返回原始 .exe 路径，不是快捷方式目标
跨平台封装时最容易忽略的三个细节
写一个 get_executable_path() 函数时，多数人卡在边界 case，而不是主干逻辑。
立即学习“C++免费学习笔记（深入）”；
- 符号链接未解引用：Linux/macOS 返回的路径可能是链接本身，不是目标文件，必须用
std::filesystem::canonical()（C++17）或手动readlink循环 - 当前工作目录影响相对路径解析：即使 fallback 到
argv[0]，也要先std::filesystem::current_path()拼接再canonical()，否则argv[0] == "bin/app"会错判 - 权限/沙盒限制：Flatpak、Snap、macOS App Sandbox 下，
/proc/self/exe可能不可读，_NSGetExecutablePath()可能返回"/path/to/App.app/Contents/MacOS/App"—— 这是合法路径，但和开发时预期不同
真正难的不是调哪个 API，而是判断「此刻哪个路径最接近用户心智中的‘这个程序在哪’」。比如调试时用 IDE 启动，argv[0] 可能是临时构建路径；而打包发布后，用户只认安装目录下的那个路径。没有银弹，只有按场景权衡 fallback 顺序。
