atob解Base64压缩报文会失败或乱码，因其输出为含非法UTF-16码点的二进制字符串；正确流程是atob→Uint8Array→inflate→TextDecoder。
直接用 atob 解 Base64 压缩报文会报错或得到乱码——因为 atob 只能处理纯 ASCII 字符串，而 GZIP 压缩后的二进制数据经 Base64 编码后，解码出来仍是二进制字节流，不是可读文本。
为什么 atob("H4sIAAAAAAA...") 会失败或返回乱码
atob 的输入必须是合法 Base64 字符串，输出是原始字节组成的字符串（每个字符 charCodeAt() 值 ∈ [0, 255]）。但 WebSocket 服务端若用 GZIP 压缩再 Base64 编码，客户端收到的是压缩后的二进制数据的 Base64 表示。直接 atob 后得到的是“二进制字符串”，不能当 UTF-8 文本直接 console.log 或 JSON.parse。
- 错误现象：
atob("...")成功执行，但后续JSON.parse(decoded)报SyntaxError: Unexpected token - 根本原因：GZIP 输出是任意字节，
atob解出的字符串里含非法 UTF-16 码点（如\x00\x1f\x8b...），JS 引擎无法解释为有效字符串 - 关键区别：
btoa/atob不是“文本编解码器”，它们绕过编码层，做的是字节 ↔ Latin-1 字符串的直射映射
正确还原流程：atob → Uint8Array → inflate → TextDecoder
必须把 atob 的输出立即转成 Uint8Array，再交给解压库（如 pako）处理，最后用 TextDecoder 转 UTF-8 文本。不能跳步。
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 先用
atob解 Base64 得到二进制字符串：const binStr = atob(base64Data) - 将字符串逐字符转为字节：
const bytes = new Uint8Array(binStr.length); for (let i = 0; i - 用 pako.inflate 解压：
const inflated = pako.inflate(bytes)（需提前import pako from 'pako'） - 用
TextDecoder还原文本：const text = new TextDecoder('utf-8').decode(inflated) - ⚠️ 注意：服务端必须确认用的是 GZIP（不是 deflate raw），否则
pako.inflate会抛invalid block type
WebSocket onmessage 中的实际处理代码
假设服务端推送的是 BinaryWebSocketFrame（即二进制帧），且 payload 是 GZIP+Base64 编码的字符串（常见于兼容性兜底设计）：
websocket.onmessage = function(event) {
if (typeof event.data === 'string') {
try {
// 1. Base64 解码
const binStr = atob(event.data);
// 2. 转 Uint8Array
const bytes = new Uint8Array(binStr.length);
for (let i = 0; i
- 如果服务端发的是纯二进制帧（
ArrayBuffer），就完全不需要atob，直接new Uint8Array(event.data)→pako.inflate - 浏览器不支持
pako时，可用DecompressionStream（Chrome 110+、Firefox 120+），但需配合ReadableStream，兼容性更差 -
atob对输入长度有隐式限制（约 2^27 字符），超长 Base64 会触发"InvalidCharacterError"，此时应改用分块或服务端切片
真正容易被忽略的点是：从 atob 到 Uint8Array 的转换这一步，很多人以为 atob 返回的就是“字节数组”或“可直接解压的 buffer”，其实它返回的是一个“伪字符串”——每个字符代表一个字节，但 JS 字符串本身不是字节容器，必须显式投射。漏掉这步，后面所有解压和解码都会失效。
