Windows 下最稳方式是 GetModuleFileNameW 配合宽字符缓冲区，Linux/macOS 用 readlink("/proc/self/exe") 或 _NSGetExecutablePath()；绝不可依赖 argv[0]。
Windows 下用 GetModuleFileName 获取 exe 路径最稳
在 Windows 上，GetModuleFileName 是获取当前可执行文件绝对路径的首选，它直接读取加载器填入的模块信息，不依赖环境变量或命令行参数，稳定性高。
常见错误是传入 NULL 或忽略返回值：函数返回实际写入字符数，不是布尔成功标志；缓冲区太小会截断路径，且不自动补 \0 —— 必须手动检查返回值是否 == 0 或 >= 缓冲区大小。
实操建议：
- 用
MAX_PATH（260）不够安全，优先用GetModuleFileNameW+wchar_t缓冲区，大小设为MAX_PATH * 2或动态分配 - 传入
NULL作为模块句柄等价于当前进程主模块，即你自己的 exe - 路径含空格、中文、长路径（启用了 long path support）时，必须用宽字符版本，否则可能乱码或截断
- 不要对返回路径做字符串拼接后直接当文件打开——先用
PathCchCanonicalize或至少PathRemoveBackslash清理尾部反斜杠
Linux/macOS 下用 readlink("/proc/self/exe") 是事实标准
Linux 和 macOS（从 10.10+）都支持通过 /proc/self/exe 符号链接拿到当前进程的真实可执行路径，比解析 argv[0] 可靠得多——后者可能被篡改、不含路径、甚至只是脚本名。
立即学习“C++免费学习笔记（深入）”；
典型翻车点：忘记检查 readlink 返回值，或误以为返回值是长度而非字节数；更隐蔽的是没处理符号链接跳转（比如 exe 指向一个软链，而你想知道原始二进制位置）。
实操建议：
-
readlink第二个参数缓冲区必须留出 1 字节给\0，返回值是“写入的字节数”，不是含结尾的长度 - 如果路径以
(deleted)结尾，说明 exe 文件已被 unlink（常见于热更新场景），此时路径已失效，不能用于打开或读取 - 需要真实物理路径？再套一层
realpath()，但注意它会跟随所有符号链接，可能绕过你期望的“启动时所用路径” - macOS 不支持
/proc，得 fallback 到_NSGetExecutablePath()，它返回相对路径（如./myapp），需配合getcwd()拼接，且不保证存在
C++ 跨平台封装要注意路径分隔符和编码
即使你分别实现了 Windows 和 Unix 的逻辑，拼起来用时仍容易出错：Windows 返回反斜杠 \，Linux/macOS 返回正斜杠 /；宽字符路径在 Linux 下无意义，但若混用 wstring 和 readlink 就会崩。
关键不是“统一成一种分隔符”，而是“按目标系统习惯构造路径”——比如生成配置文件路径时，用 std::filesystem::path 拼接，它会自动适配；但如果你手动字符串拼接，就得条件判断 #ifdef _WIN32。
实操建议：
- C++17 起，优先用
std::filesystem::canonical("/proc/self/exe")（Linux）或std::filesystem::absolute(argv[0])（fallback），但注意前者在 macOS 不可用 - 避免把路径存为
std::string后反复.replace()替换分隔符——效率低且易漏，直接用std::filesystem::path::replace_filename()等接口操作 - 日志或调试输出路径时，务必用原始字符串（raw string literal）或双反斜杠显示 Windows 路径，否则控制台可能误解析转义
为什么不用 argv[0] 直接取路径
argv[0] 看似最简单，但它根本不可信：可以被任意修改（execve 第二个参数）、可能是相对路径、可能不含目录（仅文件名）、甚至为空。生产环境里，它只适合做“程序名识别”，不能用于定位资源或构建其他路径。
一个典型误用：用 dirname(argv[0]) 得到“当前目录”，结果在 systemd service 或 IDE 启动时工作目录与 argv[0] 所在目录完全无关，导致配置文件加载失败。
实操建议：
- 永远不要用
argv[0]构造配置路径、数据目录或插件搜索路径 - 如果必须 fallback，先尝试
GetModuleFileName/readlink("/proc/self/exe")，失败后再退化到argv[0]并加日志告警 - 测试时故意用
cd /tmp && ./myapp和/full/path/to/myapp两种方式启动，验证路径逻辑是否一致
跨平台路径获取真正难的不是 API 调用，而是“路径语义”的理解差异：Windows 的模块路径是加载时确定的，Linux 的 /proc/self/exe 是运行时符号链接，而 argv[0] 根本就不该算作路径来源。一旦混淆这三者的生命周期和可靠性边界，后续所有基于它的路径操作都会埋雷。
