atob返回Latin-1字符串而非Uint8Array，需用Uint8Array.from(atob(cleaned), c => c.charCodeAt(0))或预分配循环转换；Base64须清洗前缀、非法字符并补等号。
atob 本身不能直接产出 Uint8Array，它只返回 Latin-1 字符串；必须手动将每个字符的码点转为字节，再构造 Uint8Array —— 这是唯一可靠、无需 polyfill 的浏览器原生路径。
为什么 atob 返回的字符串不是二进制数据
很多人误以为 atob() 解码后就得到了“字节数组”，其实它返回的是一个字符串，其中每个字符的 charCodeAt(0) 值恰好落在 0–255 范围内（即 Latin-1 映射）。这个字符串不是 ArrayBuffer，也不是 TypedArray，不能直接用于 fetch、Blob 或加密 API。
- 直接
new Blob([atob(str)])会报错：Blob 构造器不接受字符串 -
Uint8Array.from(atob(str))无效：它会把字符串当 iterable，逐字符调用undefined，结果全是 0 - 若配置含中文或 UTF-8 内容，未做预处理就调
atob()，大概率触发InvalidCharacterError或解出乱码
清洗 Base64 字符串的必要步骤
WebSocket 或 fetch 接收的 Base64 很少是“干净”的。跳过清洗几乎必然失败。
- 移除 Data URL 前缀：
base64Str.replace(/^data:[^;]*;base64,/, '') - 过滤非法字符（换行、空格、制表符、非 Base64 字母）：
base64Str.replace(/[^A-Za-z0-9+/=]/g, '') - 补足等号至长度为 4 的倍数：
base64Str.padEnd(Math.ceil(base64Str.length / 4) * 4, '=') - 可选校验：解码前检查长度是否符合 Base64 规则（4n），避免静默截断
从 atob 到 Uint8Array 的两种安全写法
推荐优先使用 Uint8Array.from() 形式，语义清晰、无中间数组；大体积数据（>2MB）建议改用循环 + 预分配，减少 GC 压力。
- 简洁版（适合中小配置）：
const uint8 = Uint8Array.from(atob(cleaned), c => c.charCodeAt(0)) - 高效版（显式控制内存）：
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>} - 严禁写法：
new Uint8Array(atob(cleaned))—— 它会把字符串当作 length 参数，创建空数组
配置流场景下的关键避坑点
如果你接收的是分片配置（如多个 WebSocket message 拼成一个完整 Base64），最容易被忽略的是拼接时机和内存释放。
- 不要先拼 Base64 字符串再解码：字符串拼接会翻倍内存占用（Base64 本身已膨胀 33%，拼接后再解码更糟）
- 应先各自解码为
Uint8Array，再用set()拼到目标缓冲区：target.set(chunk, offset) - 解码完成后立即丢弃
binStr引用（如设为null），帮助 GC 回收 Latin-1 字符串 - 若配置最终要解析为 JSON，别在 Uint8Array 上硬搞 —— 先用
TextDecoder("utf-8").decode(uint8)转回字符串再JSON.parse()
真正难的不是调用 atob()，而是确认你拿到的字符串是合法 Base64、清洗得够干净、且后续没把它当“二进制对象”误用。每一步漏掉，都会在运行时表现为静默失败或内存暴涨。
