gopsutil 的 process.Process 实例不能直接复用，因其字段为创建时快照，需显式调用 p.Refresh() 才能更新状态，否则 CPUPercent() 等方法返回错误值或 -1.0；批量处理时须先校验 pp.IsRunning() 防止“no such process”错误。
为什么 gopsutil 的 process.Process 实例不能直接复用
你拿到一个 process.Process 对象后，以为调用 p.CPUPercent() 或 p.MemoryInfo() 就能实时获取最新值——其实不是。这个对象本身不自动刷新，所有字段（比如 CPU、MemoryInfo）都是创建时快照的，后续再调用方法会基于旧数据算出错误结果。
- 必须显式调用
p.Refresh()才能更新内部状态，否则CPUPercent()会返回 0 或异常值 -
Refresh()不是纯读取：它会触发系统调用（如读/proc/[pid]/stat），频繁调用有开销，但跳过它就等于监控失效 - 跨平台行为一致，但在 macOS 上部分字段（如
NumThreads）可能因权限缺失返回 0，需提前检查err
如何安全地批量获取进程列表并过滤目标进程
用 process.Processes() 拿到全部进程后，别急着遍历调用 pp.Name() ——很多进程在你读取过程中已退出，直接调用会触发 "no such process" 错误。
- 每次访问前先用
pp.Pid做非空判断，再加一层pp.IsRunning()校验（它内部会捕获常见退出错误） - 想按名称查进程？别用
strings.Contains(pp.Name(), "xxx")，因为pp.Name()只返回二进制名（如"nginx"），不含路径或参数；要匹配完整命令行得用pp.Cmdline()，但它在 Windows 上不可用 - Linux 下可结合
pp.Username()过滤用户级进程，但注意：该字段返回的是 UID 对应的用户名字符串，若系统无对应条目（如容器环境），会返回空或数字 UID
CPUPercent() 返回值为 -1.0 的真实原因和应对
这不是 bug，而是 gopsutil 明确设计的信号：表示无法计算 CPU 使用率。常见于进程刚启动、已退出、或两次采样时间间隔太短（
- 必须检查返回值是否为
-1.0，不能直接参与平均或告警逻辑 - 正确做法是：首次调用
CPUPercent()后 sleep 至少 200ms，再调第二次才能得到有效值；单次调用永远无效 - 如果你在循环里每秒采集一次，记得对每个进程维护自己的“上次采样时间”，避免不同进程共用同一时间基线导致计算错乱
内存单位混淆：为什么 MemoryInfo().RSS 看起来小得不合理
RSS（Resident Set Size）单位是字节，但很多人误以为是 KB 或 MB，直接打印出来像 12582912 就懵了——这其实是 12MB。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 别手动除以 1024 再除 1024，用
bytesize这类库或自己写个简单换算函数更可靠 -
VMS（Virtual Memory Size）通常比RSS大得多，包含已分配但未实际使用的内存页，监控意义弱于RSS - Docker 容器内进程看到的
RSS是宿主机视角的物理内存占用，不会受memory.limit_in_bytes限制影响——所以即使容器内存超限被 OOM kill，RSS值仍可能持续上涨
进程监控最麻烦的从来不是“怎么拿到数据”，而是“怎么确认数据此刻真的代表进程状态”。每次调用前多一次 IsRunning()，每次计算前多一次 -1.0 判断，这些看似啰嗦的检查，才是让工具在生产环境跑稳的关键。
