disk.iocounters()返回的是系统启动以来的累计值而非瞬时速率，需两次调用取差值计算io速率，且须设备对齐、异常过滤及跨平台适配。
直接读 /proc/diskstats 或调用 disk.IOCounters() 是最可行的路径，但两者都必须做差值计算、设备对齐和异常过滤——没有“开箱即用”的 IO 速率。
为什么 disk.IOCounters() 返回的 ReadCount 不是每秒读次数
disk.IOCounters()（来自 github.com/shirou/gopsutil/v3/disk）返回的是自系统启动以来的累计值，不是瞬时速率。它和 /proc/diskstats 本质一致，只是做了跨平台封装。
- 必须至少两次调用，间隔 ≥100ms，否则差值常为 0（内核更新有最小粒度）
- 传入设备名切片（如
[]string{"sda", "nvme0n1"}）才能精准限定范围；不传则返回所有设备，含 loop、ram 等伪设备 - Windows 下需管理员权限，否则跳过部分设备或返回全零值；macOS 对 APFS 卷不支持，
IOCountersStat中对应字段为空 - 字段含义：
ReadCount/WriteCount是完成次数，ReadBytes/WriteBytes是字节数，ReadTime/WriteTime是毫秒级总耗时（可用于算平均延迟）
手动解析 /proc/diskstats 容易踩哪些坑
Linux 下直接读 /proc/diskstats 灵活但极易出错，常见问题集中在字段定位、单位换算和数据一致性上。
- 不要硬按列号取值（如“第4列是读次数”），不同内核版本列数不同（11 列 vs 14 列），要用空格切分 + 过滤空字符串后取第 3 字段为设备名，再匹配行
- 扇区单位是 512 字节，
sectors_read× 512 才是真实字节数；别直接当字节用 - 文件无锁更新，单次读可能跨更新边界，导致某字段突变为 0 或负值；建议连续两次读取，差值为负则丢弃该设备本次采样
-
os.Open("/proc/diskstats")可能 panic：容器环境或 Alpine 等精简系统可能未挂载/proc；务必先os.Stat检查存在性，失败后可退到/sys/block/*/stat遍历 - 别用
bufio.Scanner直接读——某些内核版本末尾不带换行符，Scanner.Scan()会卡住；改用io.ReadAll+strings.Split更稳
IO 压力到底看哪个字段组合
只看 ReadCount 或 WriteBytes 总量毫无意义；真正反映负载的是速率、延迟与队列深度的组合。
- IOPS = (
current.ReadCount - prev.ReadCount+current.WriteCount - prev.WriteCount) / 采样秒数 - 平均读延迟 ≈
(current.ReadTime - prev.ReadTime)/(current.ReadCount - prev.ReadCount)（毫秒/次） - 设备忙时占比 =
(current.IOTime - prev.IOTime)/ (采样秒数 × 1000) —— 超过 70% 就值得警惕 - 加权等待时间（
weighted_io_ms，/proc/diskstats第 13 列）比io_ticks更敏感，它已按队列长度加权，数值高说明请求在排队，磁盘成瓶颈
跨平台统一采集时，gopsutil/disk 是首选，但得接受 Windows 权限限制和 macOS 的 APFS 缺失；若只能裸写，/proc/diskstats 解析逻辑必须包含设备名精确匹配、扇区换算、负值过滤和双采样校验——少一步，监控曲线就失真。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
