最轻量可靠获取Linux CPU使用率的方法是读取/proc/stat并两次采样计算差值，真实使用率=1-(idle2-idle1)/(total2-total1)；内存应优先用MemAvailable字段，单位kB需转字节；SSE推送需手动Flush且前端监听error。
Go 怎么获取 Linux 系统实时 CPU 使用率
直接读 /proc/stat 是最轻量、最可靠的方式，比调用 runtime.NumCPU() 或 runtime.GOMAXPROCS() 有用得多——后者只返回逻辑 CPU 数量，不反映实际负载。
关键点在于：需要两次采样（间隔 100–500ms），计算 jiffies 差值。cpu 行前 4 列（user、nice、system、idle）之和是总时间片，idle 单独代表空闲时间。真实使用率 = 1 - (idle2-idle1)/(total2-total1)。
- 别用
time.Sleep(1 * time.Second)做间隔——Go 调度可能让实际间隔漂移，建议用time.AfterFunc或固定 tick - 注意
/proc/stat每行开头是cpu（所有核汇总）或cpu0、cpu1（单核），仪表盘通常只需cpu - 如果读取失败（比如容器里没挂载
/proc），os.Open("/proc/stat")会返回*os.PathError，需显式检查err != nil
Go 读内存信息为什么总比 free -h 显示得少
因为 free 显示的是 /proc/meminfo 里的 MemTotal - MemFree - Buffers - Cached（即“已用”），而新手常只减 MemFree，漏掉内核缓存部分。
仪表盘要展示“真实可用内存”，应优先看 MemAvailable 字段（Linux 3.14+），它已剔除不可回收缓存； fallback 时再算 MemTotal - MemFree - Buffers - Cached + SReclaimable。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
MemAvailable在某些旧内核或容器环境可能不存在，必须做字段存在性判断，不能硬 parse 第 3 行 - 字段值单位是 kB，不是字节，别忘了乘 1024——否则显示 “1.2 MB 内存” 就离谱了
- 读
/proc/meminfo用bufio.Scanner逐行扫比全读进[]byte更省内存，尤其在低配设备上
用 http.Server 推送实时数据时连接频繁断开
默认 HTTP/1.1 连接会被客户端（比如浏览器）或中间代理（Nginx）主动关闭，导致轮询中断。这不是代码 bug，是协议行为。
两种解法：要么改用 Server-Sent Events（SSE），用 text/event-stream；要么保持长连接但手动管理心跳。SSE 更简单，且原生支持自动重连。
- 响应头必须设
Content-Type: text/event-stream和Cache-Control: no-cache，否则 Chrome 会缓存 - 每条数据末尾要加双换行
\n\n，字段用data:开头，例如：data: {"cpu": 23.4, "mem": 65.1}\n\n - 别用
json.Encoder直接写 struct——它不加data:前缀，得自己拼字符串或封装一层
前端用 EventSource 接 SSE 数据但收不到更新
常见原因是后端没正确 flush 输出缓冲，或者前端没处理 error 事件导致静默失败。
EventSource 默认每 3 秒重连一次，但首次失败或网络抖动时不会报错，只会沉默。必须监听 error 并打印日志，否则根本不知道断了。
- 后端每次写完数据后，务必调用
responseWriter.(http.Flusher).Flush()，否则 Go 的http.ResponseWriter会攒着不发 - 前端
EventSource实例要保存在作用域外，避免被 GC；同时绑定onerror，里面检查eventSource.readyState是否为 0 - Chrome 开发者工具的 Network 面板里，SSE 请求状态栏显示 “pending” 是正常的——只要没关，就说明连接活着
真正麻烦的是容器环境：/proc 文件系统挂载方式、cgroup v1/v2 对 memory.stat 的影响、以及不同发行版内核对 MemAvailable 的实现差异。这些没法靠一个通用函数兜底，得在启动时探测并记录运行时环境。
