最直接方式是读取/proc/self/exe符号链接并用readlink解析；macOS应优先用_NSGetExecutablePath；Windows用GetModuleFileNameW；均需避免依赖argv[0]。
Linux/macOS 下用 /proc/self/exe 读取可执行路径
Linux 和 macOS（基于 Darwin）都支持通过 /proc/self/exe 符号链接获取当前进程的可执行文件路径。这是最直接、可靠的方式，不需要依赖第三方库或编译器扩展。
注意：该路径是符号链接，需用 readlink 解析为真实路径；且 /proc 不是标准 POSIX 接口，但实际在主流 Unix-like 系统上稳定可用。
实操建议：
- 用
readlink("/proc/self/exe", buf, sizeof(buf)-1)获取路径字符串，返回值为实际长度，记得手动补\0 - 若返回 -1，说明
/proc不可用（极少见），应降级处理（如回退到环境变量或假设为当前目录） - 避免直接拼接字符串——路径中可能含空格或特殊字符，
readlink返回的是已转义的原始字节流，无需额外 decode - macOS 上
/proc默认不挂载，需启用：sudo sysctl kern.proc.vnodepath=1；更稳妥的做法是改用_NSGetExecutablePath（见下一条）
macOS 专用：_NSGetExecutablePath 更安全
macOS 提供了 Mach-O 原生接口 _NSGetExecutablePath，不依赖 /proc，也不需要 root 权限，是 Apple 官方推荐方式。
立即学习“C++免费学习笔记（深入）”；
它会把路径写入传入的缓冲区，并通过第二个参数返回所需缓冲区大小——这意味着首次调用常因缓冲区太小失败，需循环扩容。
实操建议：
- 先用
size = 0; _NSGetExecutablePath(nullptr, &size)获取所需大小 - 分配
char* buf = new char[size]，再调用_NSGetExecutablePath(buf, &size) - 返回成功时，路径不含
./或../，但可能含Contents/MacOS/xxx（对 App Bundle 有效） - 该函数定义在
Windows 下用 GetModuleFileNameA 或 GetModuleFileNameW
Windows 没有类 Unix 的 procfs，标准做法是调用 GetModuleFileNameA（ANSI）或 GetModuleFileNameW（宽字符）。传入 nullptr 或 HMODULE(0) 表示当前模块（即主可执行文件）。
注意：返回路径是绝对路径，但编码取决于 API 版本；若项目启用了 Unicode，优先用 W 版本并配合 std::wstring 处理。
实操建议：
- 缓冲区至少设为
MAX_PATH（260），但 Windows 支持长路径（需开启longPathAware = true并用\\?\前缀），所以更稳妥是用GetModuleFileNameW+ 动态分配 - 返回值为写入字符数，0 表示失败，需检查
GetLastError()（常见如ERROR_INSUFFICIENT_BUFFER） - 不要直接把结果当 UTF-8 用——
A版本按系统 ANSI 代码页编码，跨语言环境不可靠
跨平台封装时绕开 argv[0] 的陷阱
很多人第一反应是用 argv[0]，但它完全不可靠：可能是相对路径、无路径名（仅文件名）、已被修改、甚至为空。POSIX 明确不保证其指向可执行文件。
真正跨平台健壮的方案，是运行时探测 + 编译期条件分支，而不是试图“统一一个函数”。CMake 或构建系统里可以加 #ifdef 分支，但逻辑要收敛到一个内联函数里。
容易被忽略的关键点：
- 路径末尾可能带可执行文件名，提取目录要用
std::filesystem::path(path_str).parent_path().string()（C++17），别手写find_last_of('/')' - 某些容器环境（如 Docker）或沙盒（如 Flatpak）会重映射
/proc/self/exe，返回的路径可能是挂载前的宿主机路径，此时需结合/proc/self/cmdline或环境变量二次校验 - 如果程序被
execve替换过（比如 shell 脚本用exec ./myapp），/proc/self/exe仍指向最终二进制，而argv[0]可能还是脚本名——这正是为什么不能依赖后者
