disk.Usage() 获取剩余空间的合理起点是 usage.Available，而非 usage.Percent，因后者未扣除 root 保留空间且高估可用量；必须用 float64(usage.Available)/float64(usage.Total)*100 计算真实可用百分比，并对关键路径单独监控、设分层阈值、防毛刺干扰。
disk.Usage() 是获取剩余空间的合理起点，但直接调用它并按 usage.Percent 做判断，90% 场景下会误报或漏报——真正决定服务是否还能写入的是 usage.Available，不是 usage.Free 或 usage.Used。
为什么不能只看 usage.Percent
Linux 文件系统（如 ext4）默认保留 5% 空间给 root 用户，usage.Free 包含这部分，但普通进程根本写不进去；usage.Percent 是基于 (Total - Free) / Total 算的，天然高估可用余量。例如根分区显示 “92% used”，usage.Available 可能只剩 2GB，而 usage.Free 还有 8GB。
- 必须用
float64(usage.Available) / float64(usage.Total) * 100计算「用户真实可用百分比」 - 对
/var/log、/tmp这类路径要单独采集，避免被大目录（如/home）稀释告警灵敏度 - 若
usage.Available == 0，说明已彻底不可写（常见于低于 1% 时），需立即触发 critical 告警，不能等百分比计算结果
disk.Usage() 必须传挂载点，不能传设备名
传 "/dev/sda1" 会直接返回 ErrNotFound，因为底层调用的是 statfs(2) 系统调用，只接受已挂载路径（如 "/"、"/data"），不识别块设备节点。
- 正确做法：先用
disk.Partitions(true)获取所有分区，过滤掉"tmpfs"、"devtmpfs"等虚拟文件系统 - 对每个
Partition.Mountpoint调用disk.Usage()，而不是硬编码路径 - Windows 下路径需带盘符冒号，如
"C:"，且Partitions()不可用，得手动枚举 - 若挂载点是符号链接，必须提前用
filepath.EvalSymlinks()解析真实路径再传入，否则可能查到宿主挂载点
轮询间隔与超时控制不能省略
用 time.Sleep(30 * time.Second) 做轮询会导致周期漂移——每次 disk.Usage() 耗时几十毫秒，运行一小时后可能偏移 2–3 秒；更危险的是，NFS 挂起或权限异常会让 goroutine 卡死。
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
立即学习“go语言免费学习笔记（深入）”；
- 必须用
time.Ticker保证严格等间隔触发 - 每次 tick 启动独立
context.WithTimeout(ctx, 3*time.Second)，查完立刻cancel() - 失败时
continue，不阻塞下一个周期；不要让一次失败拖垮整个监控流 - 若某次查询卡住，
Ticker不会跳过积压 tick，必须靠超时 + cancel 主动止损
阈值判断要防整数溢出和毛刺干扰
直接写 usedPct := (usage.Used / usage.Total) * 100 会因整数除法截断丢失精度；只看单次采样值也容易被临时写入毛刺触发误告警。
- 正确计算方式：
usedPct := 100 - (100 * usage.Available) / usage.Total，先乘后除防截断 - critical 阈值建议 ≤ 5%，warning ≤ 15%；低于 1% 时
usage.Available可能归零，需单独判断 - 连续 3 次低于阈值才触发告警，恢复也需连续 3 次高于阈值才解除，避免抖动
- 输出告警时带上
usage.Total、usage.Available和挂载点路径，方便快速定位是容量小还是真快满了
关键点始终落在 Available 字段上——它不是估算值，是内核通过 statfs 返回的真实字节数。任何绕过它的策略，比如用 os.Stat 查目录大小、拼接 df 命令输出、或依赖 usage.Free，都会在 ext4 默认保留策略或 XFS 特殊行为下失效。
