WebSocket前端开发新手教程 WebSocket从入门到精通全记录【指南】-js教程-PHP中文网

websocket连接失败主因是协议、地址或服务端配置未对齐：ws/wss必须与服务端严格一致；nginx需显式配置upgrade头；域名访问时服务端须允许对应origin；http页面不可连wss，反之亦然；network面板查状态码，非101则服务端未正确处理upgrade请求。

websocket前端开发新手教程 websocket从入门到精通全记录【指南】

WebSocket 对象在现代浏览器中开箱即用，不需要引入额外库就能建立双向连接——但直接 new 一个 WebSocket 实例只是起点，真正落地时卡在连接失败、消息收不到、自动断连、跨域报错的开发者远比想象中多。

为什么 new WebSocket('ws://...') 总是触发 onerror 或直接报 failed？

绝大多数“连不上”的问题，根源不在前端代码，而在协议、地址或服务端配置没对齐：

ws:// 和 wss:// 必须和服务端实际暴露的协议严格一致；本地开发用 ws://localhost:3000，生产环境必须换 wss://api.example.com，混用必失败
浏览器控制台 Network 标签页里点开 WS 连接，看 Status 是否为 101 Switching Protocols；如果是 400 或 404，说明服务端压根没识别 Upgrade 请求，常见于 Nginx 没配 proxy_set_header Upgrade $http_upgrade
若用域名访问但服务端监听的是 127.0.0.1 或 0.0.0.0，部分服务（如某些 Node.js 的 ws 实例）默认会拒绝非 localhost 的 Origin，需显式设置 origin: '*' 或校验逻辑
Chrome 120+ 默认阻止不安全上下文（http:// 页面）创建 wss:// 连接，反之亦然；确保页面协议与 WebSocket 协议匹配

onmessage 收不到数据？检查 event.data 类型和编码

WebSocket 传输的数据默认是 DOMString（即 UTF-8 文本），但服务端可能发来 Blob 或 ArrayBuffer，而前端没做类型判断就直接 console.log(event.data)，结果看到空值或 [object Blob] —— 这不是丢包，是解析错了。

根据ui图生成前端页面

将一个或多个 UI 原型图、线框图、产品截图或设计稿转换为标准化、可直接交付的 PRD 风格文档，供产品、设计、前端和测试共同使用。适用于 Codex 需要分析 PC 网页、桌面端、移动端、响应式页面、独立弹窗、表单、表格、看板、数据大屏或多页面流程截图，还原页面结构与交互，强制套用固定文档模板，抽取跨页面共享规则，或把一组原型沉淀为单页规范文档加整体业务流程文档的场景。不适用于纯视觉审美点评、代码实现、接口设计、埋点方案、竞品分析或无 UI 输入的业务需求创作。

下载

服务端发 JSON 字符串时，前端应写 JSON.parse(event.data)；若服务端发二进制帧（比如 protobuf），event.data 就是 ArrayBuffer，需用 new Uint8Array(event.data) 处理
避免在 onmessage 里直接操作 DOM；大量消息涌入时容易阻塞渲染，建议用 requestIdleCallback 或节流后更新 UI
有些后端框架（如 Spring WebSocket）默认启用 STOMP 子协议，此时你收到的不是裸字符串，而是带 headers 和 body 的 STOMP 帧，必须用对应客户端（如 @stomp/stompjs）解析，不能直接监听 onmessage

如何让 WebSocket 在页面刷新/网络抖动后自动重连？

浏览器不会帮你重连：close 事件触发后，WebSocket 实例就不可用了，必须手动 new 新实例。简单轮询重试容易雪崩，得加退避和状态守卫。

用 socket.readyState 判断当前状态：0（CONNECTING）、1（OPEN）、2（CLOSING）、3（CLOSED）；只在 3 时才允许发起下一次重连
重连间隔建议从 1s 开始，每次失败翻倍（1s → 2s → 4s → 8s），上限设为 30s，避免密集请求打垮服务端
记录重连次数，超过 5 次后暂停自动重连，提示用户“网络异常，请手动刷新”，防止无限循环
别在 onclose 里直接 new 实例——如果服务端瞬间崩溃又恢复，可能触发竞态；推荐用 setTimeout + 标志位控制

用 fetch 或 axios 发送 WebSocket 消息？不行，别混淆协议

fetch、axios、XMLHttpRequest 全部基于 HTTP，而 WebSocket 是独立协议，二者底层 TCP 连接、帧格式、状态管理完全不同。试图用 HTTP 工具“发送 WebSocket 消息”，就像用邮局寄快递单去指挥一辆正在高速行驶的卡车——根本不在一个通信平面。

所有发往 WebSocket 服务端的消息，必须走 socket.send()；参数支持 string、Blob、ArrayBuffer、TypedArray
如果后端同时提供 HTTP 接口和 WebSocket 接口（比如登录用 POST /login，消息用 WS），注意：HTTP 登录成功后拿到的 token，通常要作为 query 参数传给 WebSocket URL（如 wss://api.example.com?token=xxx），而不是放在 Authorization header 里——WS 握手阶段不传递自定义 header
调试时别依赖 curl 测试 WebSocket；要用 wscat -c wss://... 或浏览器 DevTools 的 WS 面板，否则看不到真实帧结构