最稳直接上 gopsutil：它跨平台封装底层调用，CPU 采样需注意阻塞与非阻塞差异，内存返回实时快照而非均值，Windows 需 fallback 计算可用内存；进程监控须补全用户、状态、内存详情并限制数量；磁盘网络 IO 为累计值，需差值计算速率；定时采集需 recover、异步输出及优雅退出；跨平台字段缺失属正常，须兜底处理。
用 gopsutil 采集 CPU 和内存使用率最稳
直接上 gopsutil 是当前 Go 生态里最靠谱的选择，它封装了各平台底层调用（Linux 读 /proc/stat 和 /proc/meminfo，macOS 调 host_statistics），避免自己解析 procfs 或写 cgo。
注意两点：
-
cpu.Percent默认是阻塞 1 秒采样，想非阻塞得传time.Second以外的time.Duration，但精度会下降； -
mem.VirtualMemory返回的是实时快照，不是平均值，别误当成“过去 5 分钟均值”； - Windows 下某些字段（如
Available）可能为 0，需 fallback 到Free + Buffers + Cached的等效逻辑（Linux 才有 Buffers/Cached，Windows 用AvailPhys）。
监控进程列表时，process.Process 的 Pid 和 Name 不够用
只取 Pid 和 Name 很容易漏掉关键信息：比如同名进程（多个 nginx worker）、资源归属（谁启动的）、是否僵死（Zombie 状态）。必须补全：
- 调
p.Username()查启动用户，避免把 root 进程和普通用户进程混在一起告警； - 用
p.Status()判断状态，Z（zombie）或T（stopped）要单独标出； -
p.MemoryInfo()比p.MemoryPercent()更准，后者在多核下有时归一化异常； - 避免无限制遍历所有进程——加
limit参数或按 CPU/MEM 占用 Top N 过滤，否则在 2000+ 进程的机器上会卡顿。
磁盘 IO 和网络统计容易拿错单位或周期
disk.IOCounters 和 net.IOCounters 返回的是自系统启动以来的累计值（bytes、packets），不是每秒速率。直接打印会看到数字越来越大，毫无意义。
立即学习“go语言免费学习笔记（深入）”；
正确做法是两次采样做差，再除以时间间隔：
prev, _ := disk.IOCounters()
time.Sleep(2 * time.Second)
curr, _ := disk.IOCounters()
for name, c := range curr {
d := prev[name]
readPerSec := float64(c.ReadBytes-d.ReadBytes) / 2.0
writePerSec := float64(c.WriteBytes-d.WriteBytes) / 2.0
}
注意：
- Linux 下
disk.IOCounters默认不包含 loop 设备，要显式传true才能拿到； -
net.IOCounters在容器环境（如 Docker）里默认返回宿主机网卡，需指定pernic: true并过滤eth0或ens33等实际业务网卡； - 不同内核版本对
ReadCount/WriteCount定义不一致，建议优先用字节数（ReadBytes/WriteBytes）做指标。
定时采集时，time.Ticker 和信号处理没配好会丢数据或 panic
常见错误是把采集逻辑写在 ticker.C 的 for-select 里，但没做 recover，一旦某个 process.NewProcess 失败（比如进程已退出），整个 goroutine 就 panic 退出，后续监控全断。
稳妥写法：
- 每个采集任务起独立 goroutine，用
defer func() { recover() }()包住主逻辑； - 不要在 ticker 循环里直接
fmt.Println或写文件——IO 阻塞会导致下次 tick 延迟，改用 channel 缓存数据，另起 goroutine 异步刷盘或上报； - 监听
os.Interrupt和syscall.SIGTERM，收到后先关闭 ticker、等待正在运行的采集完成，再退出，否则最后 1–2 条数据大概率丢失。
跨平台兼容性细节藏得深：比如 macOS 上 process.Ppid() 可能返回 -1，Linux 上某些容器进程的 Cwd() 会报 operation not permitted ——这些不是 bug，是权限或内核限制，得提前兜底，不能假设所有字段都可读。
