go-echarts需用charts.NewPage()组织图表并调用page.Render()生成HTML，不支持原生实时推送，实时更新须前端轮询或WebSocket补位，且各图表标题、图例等须单独配置。
go-echarts 是目前 Golang 生态中落地最稳、更新最勤的可视化库，适合快速构建可部署的 Web 仪表盘。它不依赖前端框架，生成的是标准 HTML + JavaScript，直接 http.ServeFile 就能跑起来，省去构建、打包、跨域等环节。
但要注意：它不是终端 UI 工具，也不支持 WebSocket 原生推送——想“实时”，得自己加一层机制。
go-echarts 的初始化必须调用 charts.NewPage()
很多新手卡在页面空白，根本原因是漏掉了这一步：
-
charts.NewGauge()、charts.NewLine()等只创建单个图表实例，不构成可渲染页面 - 必须用
charts.NewPage()把多个图表组织起来，再调用page.Render() - 渲染目标是 HTML 文件路径，不是 HTTP 响应体（除非你手动写入
http.ResponseWriter）
常见错误现象：panic: runtime error: invalid memory address 或页面加载后空白，控制台无报错但图表不显示。
立即学习“go语言免费学习笔记（深入）”；
正确做法：
- 创建
page := charts.NewPage() - 用
page.AddCharts(chart1, chart2)加入图表 - 调用
page.Render("index.html")生成静态文件 - 启动 HTTP 服务时，确保该 HTML 和其引用的 JS 资源（如
echarts.min.js）可被访问
实现实时更新的关键不在 go-echarts，而在 HTTP 轮询或 WebSocket 补位
go-echarts 本身是「快照式」库：每次 page.Render() 生成一份固定 HTML，数据写死在 JS 变量里。它不提供运行时重绘 API。
所以所谓“实时”，实际有两条路：
-
轻量级方案（推荐初试）：前端用
setInterval()定时fetch("/api/metrics")拿新数据，再调用 ECharts 实例的setOption()刷新图表 -
服务端推送方案：用
gorilla/websocket建立长连接，后端conn.WriteJSON()推送结构化指标，前端监听并更新对应图表
注意点：
- 不要反复调用
page.Render()生成新 HTML——那会导致全量刷新，体验卡顿且无法保留状态 - 如果用轮询，API 返回格式建议统一为 JSON，例如：
{"cpu": 64.2, "memory": 3287}，避免前端解析负担 - WebSocket 方案里，
go-echarts只负责初始渲染；后续所有图表操作都交给前端 ECharts JS SDK
多图表组合时，charts.WithTitleOpts() 和 charts.WithLegendOpts() 必须逐图设置
go-echarts 没有全局主题配置。每个图表的标题、图例、提示框等都要单独传参：
line.SetGlobalOptions(charts.WithTitleOpts(opts.Title{Title: "请求延迟"}))gauge.SetGlobalOptions(charts.WithTitleOpts(opts.Title{Title: "CPU 使用率"}), charts.WithTooltipOpts(opts.Tooltip{Show: true}))
容易踩的坑：
- 复制粘贴时漏掉某个图表的
SetGlobalOptions()，结果只有标题没显示，以为是渲染失败 - 图例位置错乱：默认在顶部，若图表横向排列拥挤，需显式设
charts.WithLegendOpts(opts.Legend{Orient: "vertical", Left: "right"}) - 中文乱码：确保 HTML 页面声明了
<meta charset="UTF-8">，且 Go 字符串本身是 UTF-8 编码（Go 默认就是）
go-echarts 的真正门槛不在语法，而在于它把“可视化”和“实时交互”拆成了两个职责：前者由它完成，后者得你亲手接上。很多人试图用它做终端监控（比如类 termui 效果），结果发现不匹配——那是不同场景，该换工具。
