如何借助 atob 处理 WebSocket 传输的二进制 Base64 数据并还原为高效的二进制流对象

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 构造器不接受字符串类型。

• 正确做法是逐字符取码点：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 根源。