必须用 TextDecoder('utf-8') 还原 atob 解码结果，因为 atob 返回 Latin-1 字符串，直接 JSON.parse 会因 UTF-8 多字节被错误拆解而报错。
直接用 atob 解码服务端下发的二进制配置，90% 的情况会得到乱码或抛错——因为配置本质是 UTF-8 字节流，而 atob 只返回 Latin-1 字符串，不是可直接使用的文本或对象。
为什么 atob("...") 后 JSON.parse() 报 SyntaxError
服务端若把 Buffer.from({ api: "https://a.com", key: "123" }, "utf8").toString("base64") 发给前端，atob 解出来的字符串每个字符对应一个原始字节，但 JavaScript 引擎会把它当 UTF-16 字符串处理。中文、冒号、引号等 UTF-8 多字节序列被错误拆解，导致 JSON.parse() 读到非法码点而失败。
- 典型错误现象：
atob("5L2g5aW9")返回空字符串或控制台显示 符号 - 真实字节流被“解释错”了，不是数据损坏，是解码路径缺失
- 即使 Base64 字符串本身合法，也必须补上 UTF-8 语义还原这一步
正确还原 UTF-8 配置字符串的三步链
拿到 Base64 字符串后，必须严格按顺序执行清洗 → 解码 → 语义还原：
PigX UI 前端开发
下载
PigX UI Pro 前端开发指南 - Vue 3 + TypeScript + Element Plus。当用户提到 PigX UI、PigX 前端、lgb-mgui 项目、Vue 3 企业级后台开发、Element Plus 后台开发时使用此技能。
- 先清洗：去掉换行、空格、非 Base64 字符 ——
base64Str.replace(/[^A-Za-z0-9+/=]/g, '') - 再补长：确保长度是 4 的倍数 ——
base64Str.padEnd(Math.ceil(base64Str.length / 4) * 4, '=') - 最后还原：用
TextDecoder('utf-8')把atob输出转成真实 UTF-8 字符串：const binStr = atob(cleanedBase64);<br>const uint8 = new Uint8Array(binStr.length);<br>for (let i = 0; i < binStr.length; i++) {<br> uint8[i] = binStr.charCodeAt(i);<br>}<br>const configStr = new TextDecoder('utf-8').decode(uint8);<br>const config = JSON.parse(configStr);
结构化传输比裸 Base64 更可靠
如果服务端能配合改造，比在前端硬解更稳：
立即学习“前端免费学习笔记（深入）”；
- 服务端发 JSON 封装体：
{ "type": "config", "encoding": "utf-8", "data": "ey..." } - 前端根据
encoding字段决定是否走TextDecoder路径，避免猜编码 - 加字段校验（如
checksum或length）可提前发现 Base64 截断或传输丢包 - 不推荐用
escape+decodeURIComponent组合——它对部分 UTF-8 边缘序列不稳定，TextDecoder是现代标准解法
最容易被忽略的是：WebSocket 的 binaryType 设为 "arraybuffer" 时，服务端若直接发二进制 Buffer，你根本不需要 atob；只有走文本通道（比如通过 JSON 字段传 Base64）才触发这套流程。混淆传输模式，是绝大多数配置解析失败的根源。
