linux/macos 下用 readlink 读取 /proc/self/exe 是获取可执行文件绝对路径的事实标准，需预分配缓冲区、检查返回值并手动添加 '\0'；macos 默认不挂载 /proc，windows 则必须使用 getmodulefilename。
Linux/macOS 下用 readlink 读取 /proc/self/exe
绝大多数 Linux 发行版和 macOS（需兼容 procfs）可通过 /proc/self/exe 这个符号链接拿到可执行文件的绝对路径。关键是要用 readlink 系统调用，不是 std::filesystem::read_symlink（后者在旧标准或某些 libc 实现下可能失败）。
实操建议：
- 用
std::vector<char></char>预分配足够空间（如 4096 字节），传给readlink，避免栈溢出或截断 - 检查返回值：小于 0 表示失败（如权限不足、
/proc不可用），等于 0 表示空链接（极罕见） - 返回值是实际写入字节数，记得加
\0终止符再转std::string - macOS 默认不挂载
/proc，需手动启用（sudo mount -t devfs devfs /proc），生产环境不推荐依赖
Windows 下用 GetModuleFileNameA 或 GetModuleFileNameW
Windows 没有 /proc，必须调用 WinAPI。GetModuleFileNameA 返回 ANSI 路径，GetModuleFileNameW 返回宽字符路径——后者更安全，尤其路径含中文或特殊符号时。
实操建议：
- 传
nullptr作为模块句柄，表示当前进程主模块（即当前 exe） - 缓冲区大小必须传入字节数（
GetModuleFileNameA）或wchar_t个数（GetModuleFileNameW），别搞混 - 返回值为 0 表示失败，需用
GetLastError()查具体原因（如缓冲区太小会返回ERROR_INSUFFICIENT_BUFFER） - 路径末尾可能带
\0\0（多字符串格式），但单 exe 场景下直接取首段即可
std::filesystem::canonical 不可靠，慎用
有人试图用 std::filesystem::current_path() / "myapp" 再调 canonical，这在程序被软链接启动、或工作目录与安装目录不同时会失败——canonical 解析的是“当前路径下的相对路径”，不是“程序自身位置”。
常见错误现象：
- 程序放在
/opt/app/bin/，但通过/usr/local/bin/myapp（指向它的软链接）启动，canonical("myapp")会解析成/usr/local/bin/myapp，而非真实路径 - 工作目录是
/tmp，canonical("myapp")就去/tmp/myapp找，显然不存在 - C++17 的
std::filesystem在 MinGW 或旧 glibc 上可能未完全实现canonical，返回空或抛异常
跨平台封装要注意路径分隔符和编码
获取到原始路径字符串后，别直接拼接子路径。Unix 是 /，Windows 是 \；Linux 路径默认是 locale 编码，Windows 宽字符路径是 UTF-16。硬编码 "/data/config.json" 在 Windows 上可能变成 "C:\path\to\app\config.json"（反斜杠被当转义）。
实操建议：
- 统一用
std::filesystem::path构造和拼接，它自动处理分隔符（p / "data" / "config.json"） - Windows 下若用
GetModuleFileNameW，直接构造std::filesystem::path（支持const wchar_t*）；Linux 下std::string路径默认按系统 locale 解释，只要不涉及非 ASCII 字符就足够 - 避免把路径传给 C 风格 API（如
fopen）时忽略编码——Linux 下没问题，Windows 下fopen不接受 UTF-8 路径（除非用_wfopen）
最易被忽略的一点：没有“100% 可靠”的跨平台方案。Linux 依赖 /proc，Windows 依赖 WinAPI，macOS 的 /proc 是可选挂载项。如果程序可能被重命名、移动或通过 wrapper 启动，路径本身就不该作为唯一信任源——比如配置文件查找逻辑最好 fallback 到 $XDG_CONFIG_HOME 或注册表。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
