getmodulefilenamea是windows下获取exe路径最可靠方式，传null句柄、用max_path缓冲区，返回真实磁盘路径，不依赖argv[0]或当前目录。
Windows 下用 GetModuleFileNameA 获取 EXE 路径最可靠
在 Windows 上，GetModuleFileNameA（或宽字符版 GetModuleFileNameW）是获取当前进程主模块（即 EXE 文件）完整路径的标准方式。它不依赖命令行参数，也不受工作目录影响，只要程序没被卸载或移动，返回的就是磁盘上真实的 .exe 位置。
常见错误是直接读 argv[0] —— 它可能只是文件名、相对路径，甚至被恶意篡改；也有人用 GetCurrentDirectory，但那只是启动时的工作目录，和 EXE 位置完全无关。
-
hModule传NULL即可，系统自动取当前进程的主模块句柄 - 缓冲区必须足够大，推荐至少
MAX_PATH（260）字节，否则可能截断 - 返回值为实际写入长度（含终止符），若为 0 表示失败，需调用
GetLastError()查错 - 路径中可能含短文件名（如
PROGRA~1），如需规范路径，后续可用GetLongPathNameA
char path[MAX_PATH] = {0};
DWORD len = GetModuleFileNameA(NULL, path, MAX_PATH);
if (len == 0 || len >= MAX_PATH) {
// 处理错误
}
Linux/macOS 下靠 /proc/self/exe 符号链接
Linux 通过 /proc/self/exe 这个符号链接指向当前进程的可执行文件，读取其目标路径即可。macOS 没有 /proc，得用 _NSGetExecutablePath（定义在 <mach-o></mach-o> 中），它返回的是相对于根目录的路径，且不带 .app/Contents/MacOS/ 后缀（对打包应用需额外处理）。
注意：readlink 返回的是字节数，不含终止符，必须手动补 \0；而 _NSGetExecutablePath 的缓冲区大小需先用 0 调用一次获取所需长度。
立即学习“C++免费学习笔记（深入）”；
- Linux 下如果程序被
chroot或容器隔离，/proc/self/exe可能不可读或指向挂载点外 - macOS 上沙盒应用（App Store 版本）会限制该 API，返回
-1，此时只能退回到argv[0]并做realpath尝试 - 两者都可能因权限或文件系统挂载方式失效，务必加错误 fallback
跨平台封装要注意路径分隔符和结尾斜杠
Windows 用反斜杠 \，Unix 系统用正斜杠 /，但 C++ 标准库（如 std::filesystem）已能自动处理。真正容易出问题的是路径末尾是否带斜杠 —— GetModuleFileName 和 readlink 都返回完整文件路径（含文件名），而 _NSGetExecutablePath 返回的是不含文件名的目录路径（需自己拼 basename）。
- 不要手动字符串拼接路径，优先用
std::filesystem::path的/操作符 - 提取目录部分统一用
.parent_path()，比find_last_of更安全 - 若需兼容 C++17 以前版本，可封装一个轻量函数：先获取全路径，再用
strrchr（Windows）或strrchr/strrchr（POSIX）找最后一个分隔符
调试期 vs 发布期路径行为差异很大
IDE 调试时，工作目录通常是项目根目录或输出目录，但 EXE 路径仍是编译产物所在位置（比如 build/Debug/app.exe）；而安装包部署后，EXE 可能在 C:\Program Files\MyApp\ 或 /opt/myapp/bin/，此时硬编码相对路径必然失败。
更隐蔽的问题是：某些打包工具（如 Inno Setup、AppImage、macOS bundle）会把资源文件放在 EXE 同级或子目录，但路径逻辑一旦写死就很难适配多平台安装结构。
- 永远以 EXE 路径为基准定位资源，而不是假设“配置文件就在当前目录”
- 发布前务必在干净环境（非 IDE）下测试路径逻辑，尤其检查中文路径、空格、特殊符号是否被正确处理
- 日志里建议同时打印
argv[0]、getcwd()和最终解析出的 EXE 路径，方便现场排查
路径看似简单，但跨平台、打包、沙盒、符号链接这些因素叠加后，单靠一个 API 很难 100% 覆盖。最稳妥的做法是主路径用系统 API 获取，再辅以合理 fallback 和运行时校验。
