getcwd需手动管理缓冲区，易因大小不足、未检返回值等出错；filesystem::current_path是C++17推荐替代，自动内存管理、跨平台且支持Unicode，但需编译器支持。
getcwd 在 C++ 里怎么用，为什么容易出错
getcwd 是 C 标准库函数，C++ 中仍可调用，但它不返回 std::string，而是写入用户提供的字符缓冲区，必须手动管理大小和内存。常见错误包括：缓冲区太小导致截断、忘记检查返回值、未处理 NULL（失败时返回），以及跨平台路径分隔符差异。
实操建议：
- 始终传入足够大的缓冲区，例如
char buf[PATH_MAX]（PATH_MAX在 - 必须判断返回值：
if (getcwd(buf, sizeof(buf)) == nullptr) { /* 错误处理 */ } - Windows 下返回路径如
"C:\\Users\\name"，Linux/macOS 返回"/home/name"，注意斜杠方向 - 结果是 C 风格字符串，转
std::string要用std::string(buf)，不能直接构造（避免悬空指针）
filesystem::current_path 是更现代的替代方案吗
是的。std::filesystem::current_path()（C++17 起）直接返回 std::filesystem::path 对象，自动管理内存、支持 Unicode（在 Windows 上尤其关键）、跨平台行为一致，且可链式操作（如 .string()、.generic_string()）。
使用前提：编译器需开启 C++17（如 -std=c++17），链接时可能需额外选项（GCC/Clang 加 -lstdc++fs，MSVC 默认支持）。
立即学习“C++免费学习笔记（深入）”；
实操建议：
- 获取字符串形式路径用
std::filesystem::current_path().string()（本地编码）或.generic_string()（统一用正斜杠） - 它抛异常而非返回错误码，建议包裹在
try/catch中捕获std::filesystem::filesystem_error - 与
getcwd语义完全一致——都是进程当前工作目录，不是可执行文件所在目录
current_path() 和 getcwd() 的性能与兼容性差异
两者底层通常都调用系统 API（如 Linux 的 getcwd(2)，Windows 的 GetCurrentDirectory），性能差别可忽略。但兼容性上差异明显：
-
getcwd：C++98 起可用，无依赖；但在嵌入式或 freestanding 环境中可能不可用 -
std::filesystem::current_path：C++17 标准组件，但部分旧编译器（如 GCC 8 以下）实现不完整，Android NDK r21 前默认禁用 - Android/iOS 等移动端：
getcwd更稳妥；桌面/服务端开发优先选filesystem - 如果项目需支持 C++14 或更低，只能用
getcwd，并自行封装健壮的字符串包装函数
获取可执行文件所在目录不能只靠 current_path()
这是最常被混淆的点：std::filesystem::current_path() 和 getcwd() 都返回**进程启动时的工作目录**，不是 main 所在的二进制文件位置。例如你从 /tmp 运行 /usr/bin/myapp，两者都返回 /tmp。
要获取可执行文件路径，需平台特定方法：
- Linux：读取
/proc/self/exe符号链接，再用readlink - macOS：用
_NSGetExecutablePath()（ - Windows：用
GetModuleFileNameA(nullptr, ...) - C++26 可能引入
std::filesystem::executable_path()，但目前没有标准方案
别把 current_path 当成“程序根目录”来用，这个误解会导致配置文件加载失败、资源路径错乱——而且问题在开发机上常因巧合掩盖，上线后才暴露。
