atob不能直接处理WebSocket二进制Base64数据，需先清洗校验Base64字符串（去除非法字符、补等号），再用atob解码为Latin-1字符串，最后通过charCodeAt转为Uint8Array还原二进制。
atob 本身不能直接处理 WebSocket 传来的二进制 Base64 数据——它只接受字符串，且要求输入是合法 Base64 编码的 ASCII 字符串。你必须先确保传输层发送的是合规 Base64，再用 atob 解码为 Latin-1 字符串，最后手动转成 Uint8Array 或 Blob。
WebSocket 收到的 Base64 字符串必须是标准格式
常见错误是后端（如 Node.js）用 Buffer.toString('base64') 发送，但前端未校验是否含非法字符（如换行、空格、非 Base64 字符）。atob 遇到任何非法字符都会抛 InvalidCharacterError。
- 接收消息时先做基础清洗：
base64Str.replace(/[^A-Za-z0-9+/=]/g, '') - 检查长度是否为 4 的倍数，不足则补等号：
base64Str.padEnd(Math.ceil(base64Str.length / 4) * 4, '=') - 避免在 WebSocket 消息中混用 JSON 和 Base64：推荐结构化发送，例如
{ "type": "chunk", "data": "SUQs...", "seq": 0 }，而非裸字符串
atob 解码后必须转成 Uint8Array 才算真正还原二进制
atob 返回的是“Latin-1 字符串”，每个字符对应一个字节（码点 0–255），但这不是二进制对象。直接 new Blob([atob(str)]) 会出错，因为 Blob 构造器不接受字符串类型。
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 正确做法是逐字符取码点：
const bytes = new Uint8Array(atob(base64Str).split('').map(c => c.charCodeAt(0))) - 更高效写法（避免中间字符串）：
const binStr = atob(base64Str); const uint8 = new Uint8Array(binStr.length); for (let i = 0; i - 若需
Blob，直接传uint8：new Blob([uint8], { type: 'application/octet-stream' })
大文件分片场景下，atob + Uint8Array 是唯一轻量保真方案
WebSocket 传输大文件时，Base64 分片是常见妥协方案。但 btoa/atob 在这里不是瓶颈，真正容易崩的是内存和拼接逻辑。
- 不要把所有 Base64 片段缓存在字符串数组里再合并——解码后再拼
Uint8Array，否则内存翻倍 - 拼接多个
Uint8Array推荐用TypedArray.prototype.set，而非concat（后者返回新数组，性能差） - 务必加 CRC32 或简单
length校验：Base64 解码后长度应为原始二进制长度的 4/3 向上取整，偏差说明传输损坏
最容易被忽略的一点：WebSocket binaryType 设为 'arraybuffer' 时，服务端若直接发二进制，你根本不需要 atob——只有明确走文本通道（如 JSON 封装 Base64）才用它。混淆传输模式是 80% 的 atob 相关 bug 根源。
