std::filesystem::current_path()是C++17起获取当前工作目录最简单可靠的方式，返回path对象需捕获filesystem_error异常，必须包含<filesystem>头文件并链接-lstdc++fs（GCC）或启用C++17标准。
用 std::filesystem::current_path() 最简单可靠
C++17 起，标准库提供了跨平台的路径操作支持，std::filesystem::current_path() 是获取当前工作目录的首选方式。它返回一个 std::filesystem::path 对象，可直接转为字符串使用。
- 必须包含头文件：
#include <filesystem> - 需链接
stdc++fs（GCC）或启用 C++17（Clang/MSVC），否则链接时报错undefined reference to 'std::filesystem::current_path()' - Windows 下返回类似
"C:/Users/xxx/project"，Linux/macOS 返回类似"/home/xxx/project"，无需手动处理路径分隔符 - 若当前目录被其他进程删除或权限变更，调用可能抛出
std::filesystem::filesystem_error，建议加try/catch
#include <filesystem>
#include <iostream>
int main() {
try {
auto p = std::filesystem::current_path();
std::cout << p.string() << '\n';
} catch (const std::filesystem::filesystem_error& e) {
std::cerr << "Failed to get current path: " << e.what() << '\n';
}
}
兼容 C++11/14 时用 getcwd()，但要注意缓冲区和内存管理
在没有 <filesystem> 的旧项目中，得依赖 POSIX（Linux/macOS）或 Windows API（GetCurrentDirectoryA）。更通用的做法是用 C 标准库的 getcwd()，但它要求你提供足够大的缓冲区，且返回的是原始 C 字符串。
- 需要
#include <unistd.h>（POSIX）或#include <direct.h>（Windows），并用宏判断平台 - 不能传
nullptr给getcwd()（C++11 起虽允许，但某些 libc 实现不支持，易崩溃） - 推荐用
std::vector<char>预分配缓冲区（如 4096 字节），避免栈溢出或堆碎片 - 返回值为
nullptr表示失败，常见原因：缓冲区太小、权限不足、路径被删除
#include <vector>
#include <string>
#ifdef _WIN32
#include <direct.h>
#define GETCWD _getcwd
#else
#include <unistd.h>
#define GETCWD getcwd
#endif
std::string get_current_dir() {
std::vector<char> buffer(4096);
if (GETCWD(buffer.data(), buffer.size())) {
return std::string(buffer.data());
}
return {};
}
为什么不用 __FILE__ 或 argv[0] 替代？
新手常误以为 __FILE__（源文件路径）或 argv[0]（可执行文件路径）能代表“当前工作目录”，但它们完全不是一回事：
-
__FILE__是编译时展开的字面量，指向源码位置，运行时不可变，且不含目录分隔符标准化逻辑 -
argv[0]是启动程序时传入的可执行路径，可能为相对路径、软链接、甚至空值；即使解析出目录，也只是二进制所在目录，不是chdir()后的当前工作目录 - 两者都无法响应运行时
chdir()的变更，而current_path()和getcwd()每次调用都读取实时状态
跨平台构建时容易漏掉的链接步骤
用 std::filesystem::current_path() 编译通过，但链接失败是高频问题，尤其在 CMake 项目中。
立即学习“C++免费学习笔记（深入）”；
- GCC 必须显式链接：
target_link_libraries(myapp stdc++fs)；仅set(CMAKE_CXX_STANDARD 17)不够 - Clang 需要
-lc++fs（macOS）或-lstdc++fs（Linux），部分旧版本还需-D_GLIBCXX_USE_CXX11_ABI=1 - MSVC 2017+ 默认支持，但若关闭异常或使用 /clr，可能触发
LNK2019错误，此时应检查运行时库一致性（MD/MT）
最稳妥的方式是先用 std::filesystem::current_path().is_absolute() 做一次运行时校验，而不是只靠编译期特征检测——因为链接缺失会导致运行时报 std::system_error，而非编译错误。
