Linux/macOS 下用 /proc/self/exe 读取可执行路径最可靠，返回绝对路径且不受 chdir 影响；需用 readlink 读取后调用 dirname 提取目录，Windows 则用 GetModuleFileNameA。
Linux/macOS 下用 /proc/self/exe 读取可执行路径
Linux 和 macOS（通过 /proc/self/exe 或 /proc/<pid>/exe</pid>）能直接获取当前进程的符号链接目标，这是最可靠的方式。注意它返回的是**绝对路径**，且可能指向被重命名或移动后的文件（因为是符号链接），但对“当前执行文件所在目录”这个需求足够准确。
实操建议：
- 用
readlink("/proc/self/exe", buf, sizeof(buf)-1)读取路径，成功后用dirname()提取目录部分（注意：dirname()会修改原字符串，需拷贝一份） - 不要直接拼接字符串来删掉文件名——
std::string::rfind('/') + 1容易在路径末尾带斜杠或为根目录时出错 - 如果程序被
chdir()过，该方法仍返回启动时的真实路径，不受工作目录影响
Windows 下用 GetModuleFileNameA 获取模块路径
Windows 没有 /proc，必须调用 Win32 API：GetModuleFileNameA(NULL, ...) 返回当前可执行模块的完整路径（ANSI 版本；如需 Unicode，用 GetModuleFileNameW 并处理 wchar_t）。
常见错误现象：
立即学习“C++免费学习笔记（深入）”；
- 传入
NULL却忘了第一个参数是HMODULE，误传0或nullptr（C++11 后nullptr可用，但类型要匹配） - 缓冲区大小传错：第二个参数是缓冲区字节数，不是字符数；ANSI 下两者一致，但宽字符版必须用
sizeof(wbuf)而非MAX_PATH - 没检查返回值是否为 0 或超过缓冲区长度——失败时返回 0，截断时返回等于缓冲区大小的值
C++ 跨平台封装要注意路径分隔符和结尾斜杠
不同系统路径分隔符不同（/ vs ），且 dirname() 在 Linux 返回不带尾部 / 的路径，而 Windows 下自己截断时容易多留一个 。统一处理才能避免后续 open() 或 fopen() 失败。
使用场景提示：
- 加载同目录下的配置文件（如
config.json），推荐先获取目录路径，再用std::filesystem::path拼接：dir / "config.json" - 避免手写
str.replace("\", "/")——std::filesystem::path构造时自动 normalize 分隔符 - C++17
std::filesystem::canonical()不适用：它解析符号链接并转为绝对路径，但可能因权限或挂载点缺失失败，不如原始路径稳定
静态链接或打包工具（如 AppImage、macOS bundle）会导致路径不可靠
某些部署方式会让 /proc/self/exe 指向临时解压路径或包装器，而非开发者预期的“源发布目录”。这时获取到的“当前执行文件所在目录”其实是运行时临时位置。
性能与兼容性影响：
- Linux 下读
/proc/self/exe是轻量系统调用，无显著开销 - macOS 需改用
_NSGetExecutablePath()，且返回路径可能不完整（带../），需额外调用realpath() - 若程序以脚本方式启动（如
python main.py），该方法返回的是解释器路径，不是脚本路径——此时应改用语言自身机制（如 Python 的__file__）
真正复杂的地方在于：没有一种方法能 100% 适配所有打包、沙箱、容器场景。实际项目中，建议把“执行目录”作为可配置项 fallback，而不是完全依赖运行时推导。
