WebSocket需前后端协同，URL须匹配协议、端口和路径，Nginx需透传Upgrade头；onopen后需探测确认服务端就绪；message数据类型需主动判断并解析；error/close事件须处理重连与UI反馈。
能直接用，但必须前后端协同；单独写 new WebSocket() 不会自动连通，服务端没对应逻辑就只是个报错的连接。
WebSocket 构造函数的 URL 必须匹配后端协议和路径
浏览器里调用 new WebSocket('ws://localhost:8080') 时，这个地址不是随便写的：
-
ws://或wss://是强制前缀，不能用http://—— 浏览器会直接抛SecurityError - 端口必须和服务端监听端口一致；比如 Node.js 用
ws库启动在3000，前端就不能写8080 - 如果服务端加了路径（如
/ws/chat），前端 URL 也得带上，否则握手时 404 或被拒绝 - 生产环境走 Nginx 反向代理时，
Upgrade和Connection头必须显式透传，否则握手卡在 101 状态码之前
onopen 触发 ≠ 连接真正可用
socket.onopen 只表示 TCP 握手完成、协议切换成功，不代表服务端已准备好处理业务逻辑：
- 有些服务端框架（如 ws 库）会在
connection事件里做用户鉴权或房间分配，这期间若前端立刻send()，可能被丢弃或返回错误 - 建议在
onopen里先发一个轻量探测包（如socket.send(JSON.stringify({ type: 'ping' }))），等收到服务端确认再启用主逻辑 - 不要在
onopen里塞大量初始化消息——bufferedAmount可能堆积，尤其弱网下容易触发close事件
message 事件收到的数据类型要主动判断
event.data 的实际类型取决于服务端发的是什么，不是固定字符串：
htmlppt.skill
下载
把任意文章或文档内容转换成精美的全屏翻页 HTML 演示文件（幻灯片风格）。当用户发来一篇文章、文档链接、Markdown 内容、或粘贴的文本，并且希望生成演示用的 HTML 时触发。支持任意内容来源：iWiki 链接、KM 链接、本地文件路径、直接粘贴的文本。生成的 HTML 文件保存到本地工作区，并通过企微直接发送给用户。触发词示例：帮我把这篇文章做成PPT、转成演示文档、生成HTML幻灯片、做个演示、转成可以演示的格式、article to deck、make a slide。
立即学习“前端免费学习笔记（深入）”；
- 如果后端用
ws.send('hello')，前端event.data是string - 如果后端用
ws.send(Buffer.from([1,2,3]))，前端event.data是ArrayBuffer，需用new TextDecoder().decode(event.data)转字符串 - 常见坑：后端 JSON 序列化后发过来，前端没
JSON.parse(event.data)就直接取属性，报Cannot read property 'xxx' of string - 建议统一约定：所有业务消息都包装为 JSON 字符串，前端统一
try/catch解析，失败则丢弃或告警
error 和 close 事件不能只 console.log
这两个事件是连接异常的唯一出口，但默认行为对用户完全不可见：
-
onerror不会告诉你具体原因（比如是 DNS 失败、SSL 证书问题，还是服务端进程崩了），只抛一个空Event对象 -
onclose的event.code和event.reason才是关键线索：1006表示异常断开（大概率网络或服务端故障），4001可能是自定义的鉴权失败码 - 不处理重连逻辑的话，用户刷新页面前可能一直卡在“已断开”状态；简单重连要加退避（如 1s、2s、4s），避免雪崩式请求打垮服务端
- 真实项目里，
onclose后应清空定时器、暂停心跳、禁用发送按钮，并给出明确 UI 提示（比如“连接已断开，正在重试…”）
真正难的从来不是写那行 new WebSocket()，而是把 readyState === 1 到稳定收发之间的所有中间态都兜住——尤其是服务端重启、Nginx 超时、移动端切后台这些场景，它们不会报错，但会让 onmessage 突然静音几秒甚至几分钟。
