最可靠的方式是使用 github.com/shirou/gopsutil/v3/disk 的 disk.Usage() 获取跨平台磁盘空间信息，它自动解析符号链接、统一处理各平台差异、正确区分 Available 与 Free，并避免 unix.Statfs 在 Windows 不可用及路径解析错误等风险。
直接用 github.com/shirou/gopsutil/v3/disk，别自己调 unix.Statfs 或 syscall.Statfs —— 除非你明确只跑 Linux/macOS 且能接受 Windows 编译失败、符号链接解析错误、挂载点识别不准等风险。
为什么 unix.Statfs 在跨平台项目里大概率翻车
它在 Linux/macOS 上确实能拿到原始块数，但一到 Windows 就完全不可用：golang.org/x/sys/unix 在 Windows 下压根不编译；硬切 //go:build windows + syscall.GetDiskFreeSpaceEx 又得手动处理路径规范化、卷名提取、权限错误码映射（比如 ERROR_ACCESS_DENIED 不是 os.IsPermission 能覆盖的），稍有疏漏就返回 0 或 panic。
常见踩坑点包括：
-
statfs.Bsize和statfs.Frsize混用——总容量必须用Frsize，Bsize是 I/O 块大小，计算结果会偏大 - 误用
Bfree替代Bavail——监控告警要看非 root 用户实际能写入的空间，Bfree包含保留块，数值虚高 - 传入软链接路径却不 resolve——
unix.Statfs作用于链接本身所在文件系统，不是目标挂载点 - 没检查
err != nil就直接读stat字段——路径不存在或无权限时字段全为 0，后续计算出 “0 bytes 可用” 却不报错
disk.Usage 怎么用才不掉坑
disk.Usage 返回结构体字段语义清晰，且内部已统一处理：自动 resolve 符号链接、跳过 bind mount 冗余统计、Windows 下优先走 Win32 API，失败时回退 WMI，不用你操心构建标签或条件编译。
立即学习“go语言免费学习笔记（深入）”；
典型安全用法：
- 始终传入**挂载点路径**（如
"/"、"C:\"），别传/tmp/foo这类子目录——后者可能落在 overlayfs 或 tmpfs 上，和宿主机磁盘无关 - 检查返回的
err，不要只看UsedPercent——某些容器环境（如 rootless Pod）下可能因 cgroup 权限拿不到准确值，err非空时应降级处理 - 注意
Free和Available的区别：Available是用户真正可写空间（对应Bavail），Free是Bfree计算值，运维告警一律用Available
示例：
usage, err := disk.Usage("/")
if err != nil {
log.Printf("failed to get disk usage for /: %v", err)
return
}
if usage.Available < 1024*1024*1024 { // 小于 1GB
alert("low disk space on root fs")
}
想绕过第三方库？至少守住这三条底线
如果因合规或极简需求必须用标准库或 x/sys，务必满足：
- Linux/macOS 限定场景下，只用
golang.org/x/sys/unix，绝不用已弃用的syscall包；导入路径必须是"golang.org/x/sys/unix"，函数名是unix.Statfs - Windows 场景下，用
golang.org/x/sys/windows的GetDiskFreeSpaceEx，且必须对lpFreeBytesAvailable参数判空——该值在部分网络驱动器或权限受限卷上为nil，需 fallback 到lpTotalNumberOfFreeBytes - 所有路径传入前调用
filepath.EvalSymlinks，否则Statfs可能作用于错误挂载点
最易被忽略的一点：容器内获取的磁盘空间，反映的是**宿主机挂载点**的实际剩余，不是容器层叠文件系统的可用空间。如果你在做存储配额控制，得结合 cgroups v2 的 io.max 或 memory.max 等指标，单看 disk.Usage 会误判。
