atob返回Latin-1字符串而非Uint8Array，必须手动转换为Uint8Array才能用于二进制操作；直接使用会导致JSON.parse失败、Blob构造错误等，且需先清洗Base64字符串并补全等号。
atob 本身不产出 Uint8Array，它只返回 Latin-1 字符串；你必须手动转一次，否则后续所有二进制操作（如解压、解析协议、构造 Blob）都会失败。
为什么 atob("eyJhbGciOi...") 返回的不是可用字节数组
atob 的返回值是字符串，哪怕原始 Base64 来自 Uint8Array 或二进制 JSON，解码后每个字符只是“看起来像字节”，实际仍是 JS 字符串类型。直接 new Uint8Array(atob(str)) 会报错或生成全 0 数组——因为构造器不接受字符串参数。
- 错误现象：
JSON.parse(atob(base64Str))报SyntaxError: Unexpected token - 根本原因：Base64 解出的字符串含
\x00、\xff等控制字符，JS 字符串能存但无法被JSON.parse或TextDecoder正确解释 - 关键事实：
atob输出长度恒等于原始二进制长度，但语义上仍是“字节映射到 Latin-1 字符”，不是二进制视图
清洗 + atob + Uint8Array 三步不可省略
WebSocket 或 HTTP 响应中收到的 Base64 配置流常混有换行、空格、URL 安全字符（-/_），不清洗就调 atob 必抛 InvalidCharacterError。
- 先清洗非法字符：
base64Str.replace(/[^A-Za-z0-9+/=]/g, '') - 再补等号对齐：
base64Str.padEnd(Math.ceil(base64Str.length / 4) * 4, '=') - 最后安全解码并转
Uint8Array：const binStr = atob(cleaned);<br>const uint8 = new Uint8Array(binStr.length);<br>for (let i = 0; i < binStr.length; i++) {<br> uint8[i] = binStr.charCodeAt(i);<br>}
大配置流分片拼接时别用字符串数组缓存
若配置被拆成多个 Base64 片段（如 WebSocket 分帧推送），切忌把所有 atob() 结果先存进字符串数组再合并——这会让内存占用翻倍，且拼接字符串再转 Uint8Array 效率极低。
- 正确做法：每个片段立即
atob → Uint8Array，再用.set()拼入预分配的大缓冲区 - 示例：
const totalLength = expectedBytes;<br>const buffer = new Uint8Array(totalLength);<br>let offset = 0;<br>for (const chunk of base64Chunks) {<br> const binStr = atob(clean(chunk));<br> const chunkBytes = new Uint8Array(binStr.length);<br> for (let i = 0; i < binStr.length; i++) {<br> chunkBytes[i] = binStr.charCodeAt(i);<br> }<br> buffer.set(chunkBytes, offset);<br> offset += chunkBytes.length;<br>} - 务必校验最终
buffer.length是否匹配预期（Base64 长度 × 3 / 4 向下取整），偏差说明某片传输损坏
最容易被跳过的一步是 charCodeAt 循环——有人用 split('').map(c => c.charCodeAt(0)) 生成数组再传给 Uint8Array.from，看似简洁，但对 >1MB 的配置流会产生大量中间字符串对象，GC 压力陡增。真正在意性能和稳定性的场景，循环赋值仍是首选。
