atob解码base64后需转uint8array再用textdecoder('utf-8')还原文本，不可直接json.parse；须清洗非法字符、补等号、处理url安全base64；大报文应分片处理uint8array拼接，避免字符串拼接内存翻倍。
WebSocket 传输 Base64 压缩报文时，atob 只负责解码环节，不能直接还原为可读文本——它输出的是 Latin-1 字节流字符串，必须配合 UTF-8 解码器（如 TextDecoder）才能转成正确语义的文本。关键在于：压缩 → Base64 编码 → WebSocket 文本发送 → atob 解码 → 字节还原 → UTF-8 解码。
确保 Base64 字符串合规且可解码
WebSocket 收到的 Base64 报文常含非法字符或长度异常，直接传给 atob() 会抛 InvalidCharacterError。需先清洗和补全：
- 移除非 Base64 字符：
base64Str.replace(/[^A-Za-z0-9+/=]/g, '') - 补足等号使长度为 4 的倍数：
base64Str.padEnd(Math.ceil(base64Str.length / 4) * 4, '=') - 若服务端用 URL 安全 Base64（如
-替+、_替/），需提前替换：.replace(/-/g, '+').replace(/_/g, '/')
从 atob 输出还原 UTF-8 文本流
atob() 返回的不是“文本”，而是每个字符对应一个字节的 Latin-1 字符串。若原始压缩数据是 UTF-8 编码的文本（如 gzip 后再 base64 的 JSON），必须将该字符串转为 Uint8Array，再用 TextDecoder('utf-8') 解释：
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 构造字节数组：
const bytes = new Uint8Array(atob(base64Str).split('').map(c => c.charCodeAt(0))) - 解码为文本：
const decoder = new TextDecoder('utf-8'); const text = decoder.decode(bytes); - 避免乱码：不可直接
JSON.parse(atob(...))或decodeURIComponent(escape(...))，后者在现代环境已不推荐且对多字节字符支持不稳定
处理压缩数据（如 gzip）的完整链路
若报文是「文本 → gzip 压缩 → Base64 编码」，仅靠 atob + TextDecoder 不够，还需前端解压：
- 确认服务端是否启用压缩（如
permessage-deflate扩展）；若已启用，WebSocketbinaryType = 'arraybuffer'可直收压缩帧，无需 Base64 - 若坚持走 Base64 文本通道，解码后得到的是 gzip 二进制流，需用 pako 等库解压：
pako.inflate(bytes, { to: 'string' }) - 压缩前建议加校验字段（如原始长度、CRC32），防止传输损坏导致解压失败
性能与内存注意事项
大报文分片传输时，切忌拼接 Base64 字符串再统一解码——字符串拼接会引发内存翻倍。推荐做法：
- 每片独立清洗、
atob、转Uint8Array - 用
Uint8Array拼接（非字符串）：const full = new Uint8Array(totalLen); full.set(chunk1, 0); full.set(chunk2, chunk1.length); - 解压或解码操作延后至所有分片收齐后一次性执行，减少中间对象创建
