核心是建立并维持健壮WebSocket连接，需避开URL协议错误、混合内容拦截、DOM未就绪三坑；onmessage须类型判断+try/catch+防undef；DOM更新要节流/增量；send必须在onopen后；重连需新建实例并实现退避重试。
index.html 展示实时系统监控数据，核心不是“写个 HTML”，而是**在页面加载后立即建立并维持一个健壮的 WebSocket 连接，把服务端推送的 JSON 数据安全、可控地映射到 DOM 元素上**。没连上或连上了但解析失败，监控大屏就是静态摆设。
WebSocket 连接初始化必须避开三个坑
很多 index.html 一打开就白屏或报错，问题几乎都出在连接阶段：
-
new WebSocket('http://...')或new WebSocket('localhost:8080')—— 浏览器立刻抛SyntaxError: The URL's scheme must be either 'ws' or 'wss'；必须用ws://（开发）或wss://（生产） - 页面是
https://协议，却连ws://—— 浏览器静默拦截，控制台显示Blocked loading mixed active content；必须配好 TLS 证书，改用wss:// - 脚本放在
<head>里执行，new WebSocket()时 DOM 还没就绪，后续更新document.getElementById(...)找不到元素 —— 应确保在DOMContentLoaded后再初始化，或把<script>放在</body>前
onmessage 里不能直接 JSON.parse(event.data)
服务端发来的 event.data 类型不确定，可能是 string、Blob 或 ArrayBuffer。不加判断就 JSON.parse()，遇到二进制帧会直接崩：
- 先判断
typeof event.data === 'string'，否则跳过或走 Blob 分支（比如用event.data.text()） - 必须包
try/catch：网络抖动可能导致 JSON 截断，JSON.parse()抛异常会中断整个消息流 - 别假设字段一定存在 ——
data.cpu_usage可能是undefined，取值前做data?.cpu_usage ?? '--'防错
DOM 更新必须控制节奏，否则页面卡死
监控数据每秒推 5–10 条很常见，如果每条都直接 element.textContent = data.temp，浏览器重排压力巨大，尤其在低端设备上明显掉帧：
- 对高频数值类指标（如温度、CPU），用
requestAnimationFrame聚合更新，避免连续触发 layout - 不要整个
innerHTML = '<div>...</div>'重写 —— 只替换动态部分，例如保留<span id="temp-label">温度:</span><span id="temp-value">--</span>℃，只改temp-value的textContent - 图表区域（如 ECharts）调用
chart.setOption({series: [...]}, true)启用增量渲染，禁用全量重绘
readyState 为 0 时 send() 会静默失败
刚执行 const socket = new WebSocket(...)，socket.readyState 是 0（CONNECTING）。此时调用 socket.send() 不报错、不触发 onerror，消息直接丢弃：
立即学习“前端免费学习笔记（深入）”；
- 所有发送逻辑（如认证、订阅）必须严格放在
onopen回调里 - 如果需要在连接建立前缓存指令（比如用户切换了机柜分组），得自己维护一个待发队列，在
onopen中遍历send() - 重连后不能复用旧实例 ——
socket.close()后readyState变成0，必须new WebSocket(...)新建
index.html 就只是个好看的静态快照。 
