最稳妥方式是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 推导路径。这在多数情况看似可行，但实际场景中非常脆弱。
立即学习“C++免费学习笔记（深入）”；
-
argv[0]可能只是程序名（如"myapp"），不含路径，canonical会在$PATH中搜索，结果完全不可控 - 如果程序是通过软链接启动，
argv[0]是链接路径，canonical返回的是链接目标，而非真正被加载的二进制位置 - Windows 下
argv[0]可能被 shell 截断或包含引号，std::filesystem解析失败率高，错误码还不好捕获
真正的程序路径，只能从系统加载器那里问——Windows 问 GetModuleFileName，Linux 问 /proc/self/exe，其他路都是绕远又易错。
