Windows下应先用GetTempPath获取临时路径，再用PathStripToRoot提取驱动器根路径（如"C:"），最后调用GetDiskFreeSpaceEx；Linux/macOS需通过getenv("TMPDIR")获取临时目录路径并调用statvfs计算f_bavail*f_frsize，而非硬编码挂载点。
Windows下用GetDiskFreeSpaceEx获取临时目录所在磁盘剩余空间
直接调用GetDiskFreeSpaceEx是最稳妥的方式——它不依赖临时路径字符串解析，也不怕符号链接或重定向。关键在于先拿到临时目录路径，再提取其所在驱动器根路径（如"C:\\"），否则传入"C:\Users\xxx\AppData\Local\Temp"会失败。
常见错误是把GetTempPath返回的完整路径直接喂给GetDiskFreeSpaceEx，结果返回FALSE且GetLastError()为ERROR_INVALID_PARAMETER。
- 用
GetTempPath获取临时路径（注意缓冲区大小至少MAX_PATH） - 用
PathStripToRoot（shlwapi.h）或手动截取到第一个:\，得到根路径如"C:\\" - 调用
GetDiskFreeSpaceEx，传入根路径，接收PULARGE_INTEGER类型的lpFreeBytesAvailable
Linux/macOS用statvfs检查TMPDIR挂载点剩余空间
statvfs操作对象是挂载点（mount point），不是任意路径。临时目录可能位于/tmp、/var/tmp，甚至/dev/shm（内存文件系统），必须先通过statvfs查出该路径所属挂载点的实际设备路径，否则可能误读成根文件系统容量。
典型陷阱：硬编码"/tmp"去查，但用户设置了TMPDIR="/mnt/ramdisk"，此时查"/tmp"毫无意义。
立即学习“C++免费学习笔记（深入）”；
- 用
getenv("TMPDIR")优先获取环境变量， fallback 到"/tmp" - 对临时路径调用
statvfs(path, &buf)，不是statvfs("/", &buf) - 检查返回值是否为0，失败时
errno可能是ENOTCONN（NFS断连）或ENODEV（路径不存在） - 剩余可用字节数在
buf.f_bavail * buf.f_frsize（考虑用户配额），不是f_bfree
C++跨平台封装要注意的三个细节
没有标准库函数能直接“获取临时目录磁盘剩余容量”，所有方案都是组合调用。封装时最容易漏掉的是错误边界和权限问题——比如临时目录在受限沙箱中，statvfs可能因权限不足失败，而Windows上若临时路径指向网络驱动器，GetDiskFreeSpaceEx可能返回0且GetLastError为ERROR_NOT_READY。
- Windows下检查
GetDiskFreeSpaceEx返回值，失败时用GetLastError()区分ERROR_NOT_READY（可重试）和ERROR_ACCESS_DENIED（应降级处理） - Linux/macOS下
statvfs成功后，需验证buf.f_frsize > 0且buf.f_blocks != 0，避免除零或无效值 - 不要假设
std::filesystem::temp_directory_path()返回的路径一定可访问——它可能抛std::filesystem::filesystem_error，得提前try/catch
为什么不能只用std::filesystem::space？
std::filesystem::space看起来最简洁，但它查的是路径所在文件系统的总/可用/空闲空间，**不区分用户配额**。在启用了配额的系统（如某些Linux发行版或Windows Server域策略）上，space.available可能远大于当前用户实际还能写的字节数——而这正是临时文件写入失败的真实原因。
更隐蔽的问题：std::filesystem::space在Windows上对某些重定向路径（如WSL2的/tmp映射）可能返回主机NTFS的原始值，而非WSL内实际可用空间。
- 如果业务逻辑对磁盘余量敏感（例如预分配大临时文件），必须用原生API绕过
std::filesystem::space - macOS上
statvfs对APFS快照卷可能返回乐观值，真实可用空间需结合df -h校验 - 容器环境（Docker/Podman）中，
/tmp常是tmpfs，statvfs返回内存限制，但OOM Killer可能早于磁盘满触发
