getcwd在windows和linux上行为差异在于：linux返回无尾斜杠路径，windows可能返回带盘符及反斜杠的路径，且旧msvc不支持nullptr参数；安全封装需分平台调用_getcwd或getcwd(nullptr,0)，再统一替换为正斜杠。
getcwd 在 Windows 和 Linux 上的行为差异
直接调用 getcwd 本身是跨平台的，但实际行为有隐性分歧：Linux 返回路径不带尾部斜杠，Windows 可能返回带盘符的绝对路径（如 C: oo），且某些旧版 MSVC 的 getcwd(nullptr, 0) 不支持动态分配。这不是标准不一致，而是实现细节和默认缓冲区处理方式不同。
- Linux glibc 下
getcwd(nullptr, 0)安全可用，返回堆上分配的字符串 - Windows MSVC 2015 之前版本不支持
nullptr参数，必须传入预分配缓冲区 - 即使成功，Windows 返回路径可能含反斜杠
，而 POSIX 系统习惯用正斜杠/
封装 getcwd 的最小安全写法（C++11+）
不依赖 Boost 或第三方库，用标准 C++ 处理内存和路径分隔符。核心是先探测系统是否支持动态分配，再统一 normalize 路径分隔符。
std::string getCurrentWorkingDir() {
#ifdef _WIN32
char buffer[_MAX_PATH];
if (_getcwd(buffer, sizeof(buffer)) == nullptr) return {};
std::string path(buffer);
#else
char* buf = getcwd(nullptr, 0);
if (!buf) return {};
std::string path(buf);
free(buf);
#endif
// 统一转为正斜杠（仅用于显示或拼接，不影响系统调用）
std::replace(path.begin(), path.end(), '\', '/');
return path;
}- Windows 用
_getcwd（非getcwd）避免 MSVC 兼容问题 - Linux 用
getcwd(nullptr, 0)避免栈缓冲区溢出风险 - 不要在返回前做
std::filesystem::canonical—— 它会触发 I/O 且可能失败（如权限不足）
为什么不能直接用 std::filesystem::current_path()
看起来更现代、更“正确”，但实际引入新问题：它返回 std::filesystem::path，底层仍调用平台 API，且在某些嵌入式或精简 libc 环境（如 musl + Alpine）中可能未完全实现，或抛出 std::filesystem::filesystem_error 异常而非静默失败。
- 异常路径下，
std::filesystem::current_path()可能 throw，而getcwd只返回nullptr或空指针 - 某些交叉编译环境（如 iOS、WebAssembly）未启用
std::filesystem，编译直接失败 - 若只需字符串路径（比如日志打印、配置拼接），用
std::filesystem::path是过度设计
容易被忽略的边界情况
工作目录可能根本不存在（如被其他进程删除），或当前进程没有读权限。这时 getcwd 会失败，但很多人只检查返回值是否为空，没注意 errno。
立即学习“C++免费学习笔记（深入）”；
- Linux 下失败时 errno 可能是
ENOENT（目录被删）、EACCES（无权限）、ERANGE（缓冲区不够） - Windows 下
_getcwd失败不设 errno，要靠GetLastError()，但多数场景只需知道“获取失败”即可 - 测试时别只验证正常路径，一定要模拟
chdir /tmp && rmdir /tmp后调用，否则上线才暴露
