gopsutil比手动解析/proc更靠谱，因其跨平台封装了Linux/Windows/macOS原生API，避免字段遗漏、单位错误和权限崩溃，但需注意采样刷新、单位换算、权限检查及并发安全。
gopsutil 为什么比自己调 /proc 更靠谱
因为 Linux / Windows / macOS 的系统指标获取方式差异太大，自己解析 /proc/meminfo 或 WMI 容易漏字段、错单位、崩在权限上。gopsutil 封装了各平台原生逻辑，比如 cpu.Percent() 在 Linux 调 /proc/stat，在 Windows 调 PdhCollectQueryData，你不用管——但得知道它默认不刷新采样，直接连调两次 cpu.Percent() 可能返回全 0。
- 首次调用
cpu.Percent()必须带非零time.Duration（如1 * time.Second），否则返回空切片或 0 值 -
mem.VirtualMemory()返回的Total/Available是字节，别直接当 MB 打印，除以1024.0 * 1024.0更安全（1000系是 SI 单位，系统用的是二进制） - Windows 下若没管理员权限，
disk.Partitions(true)可能 panic，加defer-recover或提前检查os.Geteuid() == 0（Linux/macOS）或用isElevated()（Windows）
实时监控必须开 goroutine + ticker，但别乱共享 struct
gopsutil 大部分函数不是并发安全的——比如多个 goroutine 同时调 net.IOCounters(true)，可能复用内部缓存导致数据错乱。常见写法是每个监控项起独立 goroutine，用 channel 汇总，而不是让一个 struct 存所有 cpu.TimesStat 和 mem.MemStat 字段被多处读写。
- 每次采集都新建局部变量：用
stat, _ := cpu.Times(false)，别反复赋值给全局var lastCPU cpu.TimesStat - ticker 间隔别设太短（
），Linux 下 <code>cpu.Times()底层读/proc/stat有开销，高频触发会抬高%sys - 如果要用结构体聚合数据，字段加
sync.RWMutex，读用RLock()，写用Lock()，别图省事用map直接存
“实时”不等于“每秒刷屏”，要区分采集频率和上报频率
终端里 top 默认 3 秒刷新一次，不是因为它卡，而是更短间隔对人眼无意义，还浪费资源。你的监控工具也一样：cpu.Percent(1 * time.Second) 是采集耗时，但上报可以压到 10 秒一次，中间只做差值计算。
- 内存使用率建议用
mem.VirtualMemory().UsedPercent，别自己算(Total - Available) / Total * 100——Available在某些内核版本下不准，UsedPercent内部做了 fallback - 网络 IO 推荐用
net.IOCounters(false)（false 表示不重置计数器），然后和上次值做减法；设成true会清零，导致突增为负数 - 磁盘 IO（
disk.IOCounters()）在容器环境可能返回空，因为 cgroup v1 不暴露底层设备统计，得 fallback 到disk.Usage()看使用率
上线前必查的三个兼容性坑
本地跑通不等于线上能用。gopsutil 在不同发行版/内核/容器环境表现差异极大，尤其涉及 procfs 和 sysfs 路径。
立即学习“go语言免费学习笔记（深入）”；
- Docker 默认挂载
/proc是 host 的，但如果你用了--pid=host，process.PidExists()会误判容器外进程；加rootfs参数指定/proc路径可修复 - Alpine 镜像缺
libc，gopsutil 编译需加CGO_ENABLED=0，但这样会禁用部分功能（如host.Info()中的 uptime），得用sysctl命令 fallback - Kubernetes Pod 里
disk.Partitions()可能只返回/dev/root，因为其他设备节点没挂进容器，别硬依赖分区名匹配，改用Usage()的Path字段判断挂载点
最麻烦的永远不是怎么拿到数据，而是同一行代码在 CentOS 7、Ubuntu 22.04、K3s 和 WSL2 里返回的字段含义微妙不同——留好日志打点，别等报警了才翻出 fmt.Printf("%+v", stat)。
