WebSocket构造函数需协议匹配：HTTP页用ws://，HTTPS页必须用wss://；URL须无空格/未编码字符；onmessage中须判type再解析JSON；重连需节流并清理旧实例；二进制数据在DevTools不显示但已发出。
WebSocket 构造函数怎么写才不会报 SecurityError 或 SyntaxError
直接用 new WebSocket("ws://localhost:8080") 很容易失败，核心原因是协议必须匹配：HTTP 页面不能连 ws://（非加密），HTTPS 页面必须用 wss://。浏览器会直接抛 SecurityError: Failed to construct 'WebSocket': An insecure WebSocket connection may not be initiated from a page loaded over HTTPS。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 本地开发时，后端若用
http-server或 Pythonhttp.server这类不支持 HTTPS 的服务，前端必须用ws://，且确保页面也通过http://打开（比如http://localhost:5500/index.html） - 生产环境一律用
wss://，并确认后端已配置有效 TLS 证书（自签名证书会被浏览器拦截，WebSocket不走“点击继续访问”流程） -
url字符串不能带空格、中文或未编码的特殊字符；路径部分如/chat?token=abc是允许的，但token值需encodeURIComponent()处理
onmessage 回调里如何安全解析后端发来的 JSON 数据
WebSocket 的 onmessage 事件中，event.data 类型可能是 string、Blob 或 ArrayBuffer，取决于后端发送方式。常见错误是直接 JSON.parse(event.data) 导致 SyntaxError: Unexpected token o in JSON at position 1——这通常是因为后端发了 JSON.stringify({}) 以外的内容（比如对象没序列化，或用了 send({}) 直传对象）。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 始终检查
typeof event.data === 'string'再解析；否则先用new TextDecoder().decode(event.data)（针对ArrayBuffer）或event.data.text()（针对Blob）转成字符串 - 后端必须明确调用
JSON.stringify()，前端不要依赖自动序列化 - 加
try/catch包裹JSON.parse()，避免单条异常中断整个通信流
如何避免 WebSocket 断开后反复重连导致请求堆积
手动实现重连时，如果在 onclose 里立即调用 new WebSocket()，网络抖动可能触发指数级连接请求，甚至被后端限频拉黑。更糟的是，旧连接的 onmessage 可能还在执行，新连接又收到历史消息。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 用节流机制：设置
reconnectDelay = Math.min(reconnectDelay * 1.5, 30000)（上限 30 秒），首次失败后等 1s，再失败等 1.5s，依此类推 - 每次新建连接前，清除上一个实例的监听器，并置
ws.onclose = null，防止旧回调残留 - 在
onopen中才启用业务逻辑（如轮询状态、恢复订阅），避免连接未就绪就发send() - 给每个连接实例打标记（如
ws._id = Date.now()），在onmessage开头校验ws._id === currentWsId，丢弃过期连接的消息
send() 发送二进制数据时为什么 Chrome 控制台看不到内容
Chrome DevTools 的 Network 面板默认只显示文本帧（Text frames），对 ArrayBuffer、Uint8Array 等二进制数据不渲染内容，容易误判“没发出去”。但这不代表发送失败——只要 ws.readyState === WebSocket.OPEN 且没抛异常，数据就已发出。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 调试时，在
onopen后立刻发一段可读字符串（如ws.send('PING')）确认链路通；再切到二进制模式 - 后端要用
Buffer.isBuffer()（Node.js）或instanceof Uint8Array显式判断接收类型，不能只靠typeof data === 'object' - 若需观察二进制内容，可在
onmessage中用console.log(new Uint8Array(event.data))打印字节数组，或用Array.from(new Uint8Array(event.data)).map(b => b.toString(16).padStart(2,'0'))转十六进制字符串
实际项目里最常被忽略的是连接生命周期与业务状态的耦合——比如用户切换页面时没 ws.close()，后台还维持着无效连接；或者重连期间用户点了两次发送按钮，导致重复提交。这些不是 WebSocket API 本身的问题，而是状态管理没跟上。
