std::filesystem::space 返回的 available 字段单位是字节，表示当前用户可实际写入的剩余空间，而非总空闲或总容量。
std::filesystem::space 返回的是什么单位
std::filesystem::space 返回的是 std::filesystem::space_info 结构体，其中 available 字段表示「当前用户可使用的剩余字节数」，不是总空闲空间（free），也不是总容量（capacity）。这点特别容易误解——比如在启用了配额或 root 预留空间的 Linux 文件系统上，available 会显著小于 free。
实操建议：
- 始终优先用
available，它才是真正能写入的字节数；free只适合做粗略估算或系统级监控 - 注意 Windows 下 NTFS 的配额、压缩、重解析点可能影响结果；Linux 下 ext4/xfs 的 reserved blocks（通常 5%）也会计入
free但不计入available - 如果路径不存在或无权限访问，
std::filesystem::space会抛出std::filesystem::filesystem_error
获取根目录剩余空间的最小可行代码
别绕路，直接对根路径调用即可。不同平台的根路径写法有差异，但 std::filesystem 能自动处理：
#include <filesystem>
#include <iostream>
int main() {
try {
auto space_info = std::filesystem::space("/");
std::cout << "可用字节: " << space_info.available << "\n";
} catch (const std::filesystem::filesystem_error& e) {
std::cerr << "获取空间失败: " << e.what() << "\n";
}
}
说明：
Yuanfang Design System
下载
yuanfang-skills 的共享设计系统，提供 token CSS 变量、12+ 主题以及可复用的布局类型 HTML 块，供 yuanfang-html-image（以及 fu...）使用。
立即学习“C++免费学习笔记（深入）”；
- Windows 上
"/"会被自动映射为当前驱动器（如C:/），也可显式写"C:/" - macOS/Linux 下
"/"是根文件系统；若需其他挂载点（如/home），传对应路径即可 - 不要传相对路径（如
"./"）——它返回的是当前工作目录所在文件系统的空间，但语义模糊且易受 cwd 变更影响
跨平台兼容性要注意的坑
C++17 的 std::filesystem 在部分旧编译器或标准库实现中支持不完整：
- MSVC 2017+ 默认支持，但需链接
shlwapi.lib（CMake 中加target_link_libraries(... shlwapi)） - libstdc++（GCC）从 GCC 9 开始稳定支持；GCC 8 需要手动定义
_GLIBCXX_FILESYSTEM_IS_LINKED并链接-lstdc++fs - Clang + libc++ 要求 macOS 10.15+ 或 Linux 上正确配置
-lc++fs - 某些嵌入式或精简环境（如 Alpine musl）可能完全不提供
std::filesystem，此时得回退到statvfs（POSIX）或GetDiskFreeSpaceEx（Windows）
为什么 std::filesystem::space 有时返回 0 或异常值
常见原因不是代码写错，而是权限或挂载状态问题：
- 路径指向一个未挂载的设备（如
/mnt/usb目录存在但 USB 拔掉了）→ 抛异常 - 路径是符号链接且目标不可达 → 可能返回 0 或异常，取决于底层
statvfs行为 - 容器环境（Docker/Podman）中，挂载为
ro或使用 overlayfs 时，available可能恒为 0 或极小值 - 某些 FUSE 文件系统（如 sshfs、rclone mount）不支持
statvfs，std::filesystem::space会 fallback 到0或抛异常
真正难搞的是那些不报错但返回无效值的情况——比如 NFS 挂载点在服务端宕机后仍返回旧缓存数据。这种时候，仅靠 std::filesystem::space 不够，得结合 access(path, W_OK) 或尝试创建临时文件来验证实际可写性。
