应优先使用std::filesystem::space获取available字段判断可用空间，因其反映当前进程实际可写入字节数；需规范路径、捕获异常，并注意跨平台差异及文件系统语义差异。
用 std::filesystem::space 获取分区剩余空间最直接
直接调用 std::filesystem::space 函数，传入路径（任意该分区下的有效路径即可），它会返回一个 std::filesystem::space_info 结构体，其中 available 字段就是当前用户可使用的剩余字节数（注意不是 free，后者包含 root 保留空间）。
常见错误是传入相对路径或不存在的路径——std::filesystem::space 要求路径必须存在且可访问，否则抛出 std::filesystem::filesystem_error。建议先用 std::filesystem::exists 或 std::filesystem::is_directory 做前置校验。
示例：
#include <filesystem>
#include <iostream>
int main() {
try {
auto info = std::filesystem::space("/home"); // 必须是真实存在的路径
std::cout << "可用字节数: " << info.available << "
";
} catch (const std::filesystem::filesystem_error& e) {
std::cerr << "获取空间失败: " << e.what() << "
";
}
}
std::filesystem::space_info 三个字段的区别必须分清
capacity 是总容量（整个分区大小），free 是未分配的字节数（含 root 保留空间，Linux 下通常是 5%），available 才是普通用户实际能写入的剩余空间——这也是你真正该关注的值。
立即学习“C++免费学习笔记（深入）”；
在生产环境里，如果用 free 做磁盘告警阈值，可能误报：比如 1TB 分区有 50GB free，但 available 只有 0，此时写入已失败。
关键点：
available 恒成立- Linux ext4/xfs 默认保留 5% 空间给 root，
free -h显示的 “Available” 列对应的就是available - Windows NTFS 下三者通常相等（无保留空间机制）
跨平台时路径处理容易踩坑
Windows 下传 "C:\" 会被当作转义序列解析成非法路径；Linux 下传 "/" 最稳妥，但若需查某挂载点（如 /mnt/data），得确保该路径存在且非符号链接终点——std::filesystem::space 不自动解析挂载点，它只查路径所在文件系统的统计信息。
安全做法：
- Windows：用原始字符串字面量
R"(C:)"或双反斜杠"C:\\" - Linux/macOS：优先用
"/"查根分区，或用std::filesystem::weakly_canonical规范化路径后再传入 - 避免传符号链接路径（除非你明确想查链接指向位置的空间，而非链接本身所在分区）
编译和运行时依赖不能忽略
C++17 的 <filesystem></filesystem> 在 GCC 需要链接 -lstdc++fs（GCC-lc++fs；MSVC 2019+ 默认支持，但项目属性中仍需开启 C++17 标准。
运行时还依赖系统库：libstdc++.so（Linux）、libc++.dylib（macOS）、Windows 下则依赖 UCRT 和部分 API（如 GetDiskFreeSpaceEx）。
如果你在容器或精简系统里跑，可能遇到 undefined symbol: _ZTVSt15filesystem_error 这类链接错误——本质是没加链接选项，或动态库版本不匹配。
检查方法：
- 编译时加
-std=c++17并显式链接（GCC/Clang） - 运行前用
ldd ./your_program | grep filesystem确认符号解析正常 - macOS 上若用 Homebrew 安装的 Clang，可能需额外指定
-I/usr/local/include -L/usr/local/lib
实际部署时，别假设 std::filesystem::space 总是“开箱即用”——它底层调的是系统 API，权限、挂载选项（如 noexec、ro）、甚至容器 cgroup 限流都可能让调用静默失败或返回 0。
