Golang项目：实时监控CPU与内存仪表盘

最轻量可靠获取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。

• 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 的实现差异。这些没法靠一个通用函数兜底，得在启动时探测并记录运行时环境。