getcwd 获取的是进程当前工作目录，与可执行文件路径无关；需分配足够缓冲区并检查返回值和 errno。获取程序路径应使用 GetModuleFileName（Windows）、/proc/self/exe（Linux）或 _NSGetExecutablePath（macOS），而 argv[0] 不可靠。
用 getcwd 获取当前工作目录（不是程序路径）
很多人混淆“当前工作目录”和“可执行文件所在目录”。getcwd 只返回进程启动时或最近一次 chdir 设置的当前工作目录，跟你的 .exe 放在哪完全无关。它在 Linux/macOS 和 Windows（MSVC/MinGW）都可用，但行为一致——只管“当前”，不管“程序”。
常见错误现象：getcwd 返回 nullptr 或空字符串，通常是因为传入的缓冲区太小，或者调用前当前目录已被删除/权限不足。
- 必须预先分配足够大的缓冲区（推荐至少
PATH_MAX字节，Linux 上通常是 4096） - 调用后要检查返回值是否为
nullptr，并用errno判断具体失败原因（如ERANGE表示缓冲区不够） - Windows 下注意路径分隔符是反斜杠
\，但getcwd返回的仍是正斜杠风格（取决于 CRT 实现），别硬匹配
#include <unistd.h> // Linux/macOS
// #include <direct.h> // Windows 替代头文件，函数名是 _getcwd
char buf[4096];
if (getcwd(buf, sizeof(buf)) == nullptr) {
// 处理错误
}
用 GetModuleFileName（Windows）或 /proc/self/exe（Linux）拿程序路径
这才是真正获取可执行文件磁盘路径的方法。Windows 和 Linux 底层机制完全不同，没有跨平台标准 API；C++ 标准库至今不提供该功能。
使用场景：需要读取同目录下的配置文件、资源包，或做相对路径拼接时——这时依赖的是程序位置，不是当前工作目录。
立即学习“C++免费学习笔记（深入）”；
- Windows：调用
GetModuleFileName(nullptr, buf, size)，返回值是实际写入长度，需手动截断末尾可能的\0重复 - Linux：读取符号链接
/proc/self/exe，用readlink，返回的是绝对路径（即使启动时用了相对路径） - macOS 没有
/proc，得用_NSGetExecutablePath，且返回路径可能带@executable_path占位符，需进一步解析
// Linux 示例
char exe_path[PATH_MAX];
ssize_t len = readlink("/proc/self/exe", exe_path, sizeof(exe_path)-1);
if (len != -1) {
exe_path[len] = '\0';
}
跨平台封装要注意的三个坑
自己写个 get_executable_path() 函数时，最容易栽在路径规范化、内存安全和符号链接解析上。
- Linux 的
/proc/self/exe是符号链接，如果程序被硬链接或重命名过，readlink返回的是原始路径，不是你启动时用的那个名字 - 所有平台返回的路径都可能是带
./、../的非规范形式，后续拼接路径前建议先用std::filesystem::canonical（C++17）或手动展开 - 缓冲区大小不能只看
PATH_MAX：macOS 的_NSGetExecutablePath要求传入缓冲区大小，但它会返回所需大小（通过第二个参数），第一次调用常传 0 来探测长度
为什么 argv[0] 不可靠
argv[0] 看起来最直接，但它只是 shell 传进来的字符串，操作系统不保证它是绝对路径，甚至不保证它指向真实可执行文件。
常见错误现象：在终端里用相对路径启动（如 ./myapp），argv[0] 就是 ./myapp；用 PATH 启动（如直接输 myapp），它可能连目录都没有；被脚本包装、systemd 启动或 IDE 调试时，argv[0] 完全不可控。
- 它不经过任何路径解析，不做
realpath，也不处理符号链接 - 无法区分是用户输入的别名、软链接，还是真实二进制位置
- 唯一能确定的只有“启动时看到的字符串”，不适合作为资源定位依据
