disk.usage() 必须传挂载点（如/、/home）而非设备名（如/dev/sda1），因其底层调用 linux statfs 系统调用，该接口仅接受已挂载的目录路径作为参数，不识别未挂载的块设备节点。
直接用 gopsutil/disk.Usage() 获取挂载点真实使用率，比调用 df 命令更准——它走 statfs 系统调用，不受 bind mount、overlayfs 或挂载选项干扰。
为什么 disk.Usage() 必须传挂载点，不能传设备名
disk.Usage("/dev/sda1") 会返回 ErrNotFound，因为该函数只认挂载路径（如 "/"、"/home"），不解析设备节点。Linux 内核的 statfs 接口本身只接受挂载点作为参数。
- 多分区场景下，先用
disk.Partitions(true)列出所有挂载点，再过滤掉tmpfs、devtmpfs、proc等虚拟文件系统 - Windows 下必须传
"C:"（带冒号），且不支持Partitions遍历，得硬编码盘符列表 - 符号链接路径需提前用
filepath.EvalSymlinks()规范化，否则可能监听到错误挂载点
告警阈值该用 Available 还是 Percent
usage.Percent 是 (Total - Free) / Total * 100，但 Free 包含 root 保留空间（默认 5%），普通进程根本写不进去。真正决定服务是否宕机的是 usage.Available —— 普通用户还能写的字节数。
- 正确计算剩余可用百分比：
float64(usage.Available) / float64(usage.Total) * 100 - 关键路径（如
"/var/log"）要单独设阈值，避免被大目录（如"/home"）稀释 - 连续 3 次低于阈值才恢复告警，防止毛刺干扰；单次抖动不触发恢复逻辑
轮询周期怎么控制才不漂移
用 time.Sleep(5 * time.Second) 会导致累计误差：每次 disk.Usage() 耗时几十毫秒，1 小时后可能偏移 2–3 秒。长期运行必须用 time.Ticker。
- 但
Ticker不跳过积压 tick —— 若某次查询卡在 NFS 挂起上，后续所有 tick 会集中爆发执行 - 稳妥做法是加 context 超时：
ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second)，查完立刻cancel() - 查失败时直接
continue，不阻塞下一个 tick
输出格式要兼顾人眼和机器消费
终端打印可用固定宽表格（如 fmt.Printf("%-12s %6.1f%% %8s/%8s\n", ...)），但日志或 API 输出必须是结构化数据。
- 时间戳必须用 RFC3339 格式：
time.Now().Format(time.RFC3339)，方便下游做时序对齐 - JSON 输出字段名统一小写，例如
{"mountpoint":"/","available_bytes":8589934592,"total_bytes":107374182400} - 不要拼接字符串日志，避免解析歧义；同一监控项的所有字段必须在同一 JSON 对象内
最容易被忽略的是：Available 字段在某些极端情况下（如 ext4 文件系统配了大量预留 inode）可能比预期小得多，建议上线前在目标环境实测一次临界值。还有就是容器里跑监控时，/proc 和 /sys 必须挂载为只读，否则 disk.Partitions() 会静默失败。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
