gopsutil 进程遍历漏掉 root 进程是因 Linux /proc 权限限制，非 root 用户默认无法访问其他用户（含 root）进程信息；需 sudo 或能力授权（如 CAP_SYS_PTRACE）解决。
为什么 gopsutil 的进程遍历会漏掉 root 进程？
Linux 下非 root 用户调用 process.Processes() 默认看不到其他用户（尤其是 root）启动的进程，这不是 bug，是内核 /proc 权限限制导致的。gopsutil 只是忠实读取 /proc，不会自动提权。
- 运行前先确认权限：
ps aux | head -5看是否能列出 systemd、sshd 等进程；如果看不到，gopsutil也看不到 - 开发时建议用
sudo go run main.go启动，避免反复 sudo chown /proc/* - 生产环境别硬塞
sudo，改用 cap_net_raw+cap_sys_ptrace 能力授权，或用 systemd 的Capabilities=CAP_SYS_PTRACE - Windows/macOS 无此问题，但 Windows 上部分字段（如
Cwd）可能为空，因 WMI 权限策略不同
process.Process 的 Pid 和 PPid 怎么安全使用？
直接用 pid 做 map key 或 slice index 很危险——进程退出后 PID 可能被复用，而 process.Process 实例不自带生命周期感知能力。
- 别缓存
*process.Process长期使用，每次需要时都用process.NewProcess(pid)重建 - 查父进程必须用
p.Ppid()，不要依赖初始化时读到的PPid字段，因为 struct 初始化后该字段不会自动更新 - 判断进程是否存在：捕获
os.IsNotExist(err)，而不是靠pid > 0或p != nil - 跨平台注意：
PPid在 macOS 上可能返回 0（尤其容器内），需 fallback 到p.Children()反查
监控 CPU 占用率时为什么 CPUPercent() 返回 -1.0？
CPUPercent() 是个“差值型”函数，首次调用必返回 -1.0，它需要两次采样才能算出增量。这不是错误，是设计使然。
- 必须至少调用两次：
p.CPUPercent(0)（立即返回 -1.0），等几秒后再调一次才得到有效值 - 第二个参数是等待时间，设为 0 表示“不等，只返回上次计算结果”，所以首次之后再调
CPUPercent(0)才有意义 - 高频率采集（如 100ms 一次）会导致精度下降，建议间隔 ≥500ms；短于 200ms 时 Linux cgroup v2 下可能持续返回 -1.0
- 想绕过这个机制？自己读
/proc/[pid]/stat的第 14/15 字段（utime/stime），配合系统总 jiffies 计算，但失去跨平台性
如何避免 gopsutil 在容器中反复报 no such file or directory？
在 Docker/Kubernetes 中，gopsutil 默认尝试访问宿主机 /proc，但容器里挂载的是隔离视图，很多 /proc/[pid]/xxx 路径根本不存在，尤其当进程在另一个命名空间时。
立即学习“go语言免费学习笔记（深入）”；
- 启动容器时加
--pid=host（Docker）或hostPID: true（K8s），否则连Processes()都可能返回空列表 - 别依赖
p.Cmdline()获取完整命令行——容器内常因/proc/[pid]/cmdline权限或路径不可达而返回 error - 内存相关字段（如
p.MemoryInfo()）在 cgroups v2 下需确保/sys/fs/cgroup/.../memory.max可读，否则返回operation not supported - 调试时先跑
ls -l /proc/1/看关键文件是否存在，再对应检查 gopsutil 源码里读了哪些路径
真正麻烦的不是 API 调用失败，而是某些字段静默返回零值或默认值（比如 Cwd 返回空字符串而非 error），得结合上下文交叉验证。
