优先选 gopsutil 而非原生 syscall 或 /proc：它跨平台抽象了 Linux/cgroup v2、Windows/macOS 差异，但需注意 cpu.Percent() 必须传 time.Duration 才采样、disk.Usage() 在容器中需先用 disk.Partitions(true) 查真实挂载点、host.Info() 在 Alpine 中 fallback 到空字符串。
Go 语言写系统监控程序，核心不是“能不能”，而是“要不要自己造轮子”——gopsutil 已覆盖绝大多数场景，直接用它比手撸 /proc 解析或调用 sysctl 稳定得多。
为什么优先选 gopsutil 而不是原生 syscall 或 /proc
自己读 /proc/meminfo 或调用 runtime.ReadMemStats() 看内存，看似轻量，但很快会遇到：不同 Linux 发行版 /proc 字段顺序不一致、cgroup v2 下 /proc/cgroups 不再可用、Windows/macOS 完全不可用。而 gopsutil 在这些平台做了抽象和 fallback。
-
gopsutil的cpu.Percent()默认返回每核使用率，加time.Second参数才触发采样；漏传会导致返回全 0 -
disk.Usage("/path")在容器中可能因挂载命名空间隔离失败，需配合disk.Partitions(true)先查真实挂载点 - 它的
host.Info()依赖/etc/os-release，Alpine 镜像里默认没这个文件，会 fallback 到空字符串
采集 CPU/内存/磁盘时必须设对的参数
默认行为往往不是你想要的。比如 cpu.Percent() 不传 time.Duration 就不会真正采样，mem.VirtualMemory() 返回的是瞬时快照，不带历史趋势。
package main
import (
"fmt"
"time"
"github.com/shirou/gopsutil/cpu"
"github.com/shirou/gopsutil/mem"
"github.com/shirou/gopsutil/disk"
)
func main() {
// ✅ 正确：指定采样间隔，否则返回 []float64{}
percents, _ := cpu.Percent(time.Second, false)
fmt.Printf("CPU: %.1f%%\n", percents[0])
// ✅ 正确：获取当前内存使用
v, _ := mem.VirtualMemory()
fmt.Printf("Mem: %.1f%% used (%d/%d MB)\n", v.UsedPercent, v.Used/1024/1024, v.Total/1024/1024)
// ✅ 正确：先找根分区，避免硬编码 "/"
parts, _ := disk.Partitions(true)
for _, p := range parts {
if p.Mountpoint == "/" {
du, _ := disk.Usage(p.Mountpoint)
fmt.Printf("Disk /: %.1f%% used\n", du.UsedPercent)
break
}
}
}
HTTP 暴露指标时别直接用 net/http 返回 JSON
裸写 http.HandleFunc + json.Marshal 看似简单，但会快速撞上三个问题：并发采集冲突（多个请求同时调 cpu.Percent()）、无超时控制（disk.Usage() 在 NFS 挂死时卡住整个 handler）、指标格式不兼容 Prometheus。
GitHub 项目更新追踪工具 - 自动检查多个 GitHub 项目的 Releases 和 CHANGELOG，生成更新摘要与影响分析报告。支持自动化定时任务。 如何使用 最简单的方式：直接用自然语言告诉我 你可以说 我会做 「检查 GitHub 更新」 检查最新版本 「添加 vscode」 追踪新项目 「停止追踪 xxx」 移除项目 「暂停更新检查」 暂停自动化 「给我看 openclaw 报告」 展示报告 触发词：「追踪项目更新」「检查 GitHub 更新」「项目更新报告」「设置更新提醒」
立即学习“go语言免费学习笔记（深入）”；
- 用
sync.Once或sync.RWMutex保护采集逻辑，避免重复初始化或并发读写结构体 - 所有
gopsutil调用必须包在context.WithTimeout里，例如ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second) - 如果后续要对接 Prometheus，直接用
prometheus.NewGaugeVec+promhttp.Handler()，别自己拼/metrics文本
容器环境下的常见失效点
在 Docker/K8s 里跑 Go 监控程序，gopsutil 默认行为会误判宿主机资源。关键不是“能不能运行”，而是“它读的是哪一层的视图”。
- 容器内执行
host.Info()返回的是宿主机的hostname和uptime，但os.Getpid()是容器 PID，混用会导致日志混乱 -
process.Pids()默认列出所有进程，包括宿主机的，需过滤p.Pid > 0 && p.Pid < 1000000（容器 PID 通常较小）或读/proc/1/cgroup判断是否在容器中 - 想查容器自身 CPU limit，得解析
/sys/fs/cgroup/cpu/cpu.cfs_quota_us，gopsutil不提供该接口，必须手动读
真正难的不是采集数据，而是明确“这个值在当前运行环境中代表什么”。比如 cpu.Times(false) 返回的 user 时间，在容器里是受限于 cgroup 的，还是宿主机全局的——得看你是从 /proc/stat 还是 /sys/fs/cgroup/cpu/xxx/cpu.stat 读的。
