WebSocket连接失败主因是协议、地址或服务端配置未对齐：ws/wss必须与服务端严格一致；Nginx需显式配置Upgrade头；域名访问时服务端须允许对应Origin；HTTP页面不可连wss，反之亦然；Network面板查状态码，非101则服务端未正确处理Upgrade请求。
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] —— 这不是丢包，是解析错了。
- 服务端发 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 新实例。简单轮询重试容易雪崩，得加退避和状态守卫。
将一个或多个 UI 原型图、线框图、产品截图或设计稿转换为标准化、可直接交付的 PRD 风格文档，供产品、设计、前端和测试共同使用。适用于 Codex 需要分析 PC 网页、桌面端、移动端、响应式页面、独立弹窗、表单、表格、看板、数据大屏或多页面流程截图，还原页面结构与交互，强制套用固定文档模板，抽取跨页面共享规则，或把一组原型沉淀为单页规范文档加整体业务流程文档的场景。不适用于纯视觉审美点评、代码实现、接口设计、埋点方案、竞品分析或无 UI 输入的业务需求创作。
立即学习“前端免费学习笔记（深入）”；
- 用
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），而不是放在Authorizationheader 里——WS 握手阶段不传递自定义 header - 调试时别依赖 curl 测试 WebSocket；要用
wscat -c wss://...或浏览器 DevTools 的 WS 面板，否则看不到真实帧结构
真正的难点从来不在“怎么连上”，而在于连上之后怎么扛住断连、乱序、粘包、协议升级、子协议兼容、心跳保活这些细节。很多项目线上出问题，都是因为把 WebSocket 当成“高级 Ajax”来用，忽略了它是一条需要自己维护的、有状态的、长生命周期的通信管道。
