HTML5 WebSocket API怎么用原生JS编写WebSocket客户端教程【入门】-js教程-PHP中文网

websocket连接真正建立需onopen后发送ping并收到pong响应，否则属“假连接”；ws/wss必须严格区分，nginx须透传upgrade头；onmessage的data可能是arraybuffer；onerror无错误信息，需依赖onclose的code/reason判断断连原因。

html5 websocket api怎么用原生js编写websocket客户端教程【入门】

WebSocket 不是“用起来就通”的 API，它表面简单，但连接状态不可控、网络抖动易断、消息乱序无保障——直接写 new WebSocket(url) 很可能在生产环境里连不上、收不到、或反复重连失败。

下面聚焦真实开发中高频踩坑点，只讲关键动作和判断依据。

怎么判断 `WebSocket` 连接真正建立了？别只信 `onopen`

onopen 触发只代表握手完成，不代表服务端已就绪。常见错误是连接一建立就立刻 send() 认证消息，结果服务端还没加载完路由或鉴权模块，直接丢包。

服务端必须在返回 101 状态码后，再完成内部初始化（如 JWT 解析、用户 session 绑定），才开始接受业务消息
客户端应在 onopen 后发一个轻量级探测帧（如 {"type":"ping"}），等收到带 "type":"pong" 的响应，才算通道可用
如果 onopen 后 3 秒内没收到任何 message，应主动 close() 并标记为“假连接”，避免后续消息静默丢失

`ws://` 和 `wss://` 在实际部署中必须严格区分

本地开发用 ws://localhost:8080 没问题，但只要走公网域名，浏览器会直接拒绝非 wss:// 的连接（Chrome 从 2023 年起强制升级）。

anything-to-html

将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。

下载

wss:// 要求服务端有有效 TLS 证书；自签名证书在 Chrome/Firefox 中会触发 SEC_ERROR_UNKNOWN_ISSUER，且无法通过 JS 捕获或绕过
Nginx 反向代理 WebSocket 时，必须显式透传 Upgrade 头：proxy_set_header Upgrade $http_upgrade; 和 proxy_set_header Connection "upgrade";，否则握手卡在 HTTP 200，永远升不了级
开发环境想临时绕过 HTTPS 限制？只能改用 localhost 域名（浏览器对 localhost 放宽 wss 要求），别试 127.0.0.1 或自定义 hosts 域名——它们不享受该豁免

`onmessage` 收到的 `event.data` 类型不是 always string

服务端若发送 ArrayBuffer（比如图片二进制流、Protobuf 序列化数据），event.data 就是 ArrayBuffer 实例，不是字符串。直接 JSON.parse(event.data) 会报 Unexpected token in JSON at position 0。

先检查 typeof event.data === 'string'，否则用 new TextDecoder().decode(event.data) 转成字符串（仅适用于 UTF-8）
更稳妥的做法：服务端统一加个 type 字段标识 payload 格式，例如 {"type":"json","data":{...}} 或 {"type":"binary","id":"img_123"}
不要依赖 event.data instanceof Blob —— 浏览器实现不一致，Safari 可能返回 ArrayBuffer 即使你发的是 Blob

为什么 `onerror` 里拿不到具体错误原因？

onerror 事件的 event 对象是空的，没有 message 或 error 属性。这是规范限定行为，不是 bug。

真正可读的错误只出现在 onclose 的 event.code 和 event.reason 中（如 1006 表示异常关闭，1008 是策略拒绝）
想定位连接失败原因？必须监听 onopen 是否触发 + onclose 的 event.code 组合判断：未触发 onopen 就 onclose → DNS 失败 / 网络不通 / URL 错误；触发 onopen 后又 onclose → 服务端主动踢出或心跳超时
调试阶段可在 onclose 里打印 performance.now() - connectionStartTime，识别是“连接瞬间断开”还是“运行中掉线”，这对排查 Nginx idle_timeout 设置过短极有用

WebSocket 的“实时”是靠状态机维系的，不是靠语法糖。最常被忽略的是：没有心跳，连接会在 NAT 网关或中间代理上被悄无声息地回收——它不会触发 onclose，只是下一条 send() 开始失败。必须自己实现 ping/pong，且间隔要小于所有中间设备的超时阈值（通常 ≤ 30 秒）。