getmodulefilenamea（windows）、/proc/self/exe（linux）、_nsgetexecutablepath（macos）是获取可执行文件真实路径的可靠方式，应配合std::filesystem::canonical标准化处理，避免依赖argv[0]或getcurrentdirectorya。
Windows 下用 GetModuleFileNameA 获取可执行文件路径
在 Windows 上，GetModuleFileNameA 是最直接可靠的方式——它不依赖当前工作目录，而是从 PE 加载器中读取真实加载路径。传入 NULL 作为第一个参数时，它返回当前进程主模块（即 .exe）的完整路径。
常见错误是传错参数：第二个参数必须是足够大的缓冲区（比如 MAX_PATH 字节），第三个参数是缓冲区大小（不是字符串长度），且调用后需手动加 \0（如果返回值等于缓冲区大小，说明可能被截断）。
- 务必检查返回值是否为 0（失败）或 ≥
MAX_PATH（可能截断） - 路径含反斜杠
\，若后续要拼接子路径，建议统一转成正斜杠或用std::filesystem::path处理 - 不要用
GetCurrentDirectoryA替代——它返回的是启动时的工作目录，不是 exe 所在目录
Linux/macOS 下用 /proc/self/exe 或 _NSGetExecutablePath
Linux 通过符号链接 /proc/self/exe 指向当前可执行文件的真实路径（即使被重命名或移动过也会解析到原文件）。用 readlink 读取即可。macOS 不支持 /proc，得用 _NSGetExecutablePath（仅限 macOS，需链接 -framework Foundation）。
注意：readlink 返回值是实际写入字节数，不自动补 \0；而 _NSGetExecutablePath 要求传入缓冲区大小指针，且可能返回 int 错误码（如缓冲区太小会返回 -1 并把所需大小写入指针）。
立即学习“C++免费学习笔记（深入）”；
- Linux 示例：用
std::vector<char> buf(PATH_MAX)</char>分配缓冲区，再调用readlink("/proc/self/exe", buf.data(), buf.size()-1) - macOS 下若
_NSGetExecutablePath返回 -1，需先调用一次获取所需大小，再重新分配内存调用 - 两种方式都可能返回相对路径（极少见，多见于某些容器或沙箱环境），建议用
realpath()标准化
用 std::filesystem::canonical 统一处理路径（C++17）
跨平台项目里，拿到原始路径后别急着字符串拼接。用 std::filesystem::path 构造，再调用 std::filesystem::canonical 可解决符号链接、..、软链接等歧义，得到绝对、规范、可移植的路径。
但要注意：canonical 要求路径存在且可访问，如果 exe 被卸载或权限不足，会抛 std::filesystem::filesystem_error。生产环境应捕获并 fallback 到原始路径。
- 构造
std::filesystem::path时，原始字符串中的反斜杠会被自动转义，推荐用原始字符串字面量或正斜杠 - 若只需目录部分，用
.parent_path()，不要用find_last_of手动截断 - 避免在路径中混用
std::string拼接和std::filesystem::path——类型不一致易出错
为什么不能只靠 argv[0]？
argv[0] 看似简单，但它只是启动时传入的程序名，可能为相对路径、无路径前缀（如只写了 ./myapp 或 myapp），甚至被恶意篡改。在服务化场景（systemd、supervisor 启动）或 shell 封装脚本中，argv[0] 常常完全不可信。
实测中，Linux 下用 exec -a "fake" ./myapp 启动后，argv[0] 就是 fake，与真实路径毫无关系。
- 仅当明确控制启动方式且无需强可靠性时，才考虑用
argv[0]+std::filesystem::absolutefallback - 永远不要对
argv[0]做substr或find_last_of截取目录——它可能根本不含/ - 某些嵌入式或精简环境（如 musl + busybox）可能连
/proc/self/exe都不可用，此时只能接受降级策略
真正麻烦的不是“怎么拿路径”，而是“拿到之后怎么安全地拼配置文件、资源目录”。路径分隔符、大小写敏感性、符号链接循环、挂载点变更——这些细节在开发机上不出问题，上线后才突然暴露。建议所有路径操作都包裹在 std::filesystem 接口里，别自己写 str.replace。
