atob() 不能直接解码 WebSocket 收到的 Base64 字符串，因其仅支持 Latin-1 字节流，而 WebSocket 数据多为 UTF-8 编码；需先 atob() 再用 TextDecoder 解码为 UTF-8 字符串。
atob() 不能直接解码 WebSocket 收到的任意 Base64 字符串——尤其当原始内容含中文、Emoji 或二进制数据时，会立即抛出 InvalidCharacterError。 它只认 Latin-1 范围（0x00–0xFF）的字符串，而 WebSocket 传输的 Base64 往往来自 UTF-8 编码的业务文本或 ArrayBuffer，必须先做编码对齐。
为什么 WebSocket 收到的 Base64 用 atob() 直接解会报错
WebSocket 的 onmessage 回调中，event.data 可能是 string 或 ArrayBuffer。如果后端发的是 UTF-8 文本再 Base64 编码（比如 btoa(encodeURIComponent("你好"))），前端却只用 atob(event.data)，就会失败——因为 atob() 解出来的仍是 Latin-1 字节流，不是合法 UTF-8 字符串。
常见错误现象：
-
Uncaught DOMException: Failed to execute 'atob' on 'Window': The string to be decoded is not correctly encoded.（Base64 格式本身不合法，比如长度非 4 倍数、含非法字符） -
Uncaught URIError: URI malformed（后续用decodeURIComponent时字节序列非法） - 解出来是乱码，如
ä½ å¥½（UTF-8 字节被当 Latin-1 解释）
正确还原流程：先 atob()，再按 UTF-8 语义重建字符串
核心原则：把 atob() 输出的“伪二进制字符串”转成 Uint8Array，再用 TextDecoder 按 UTF-8 解码。
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
实操建议：
- 优先使用
TextDecoder（现代浏览器全支持，无需 polyfill） - 避免
escape/unescape + decodeURIComponent组合——它在处理某些 Unicode 码点（如代理对、U+D800–U+DFFF）时不可靠 - 若需兼容 IE，改用
js-base64库的Base64.decode()，它内部做了编码归一化
示例代码：
ws.send(new TextEncoder().encode("你好").buffer)
- 直接用
new TextDecoder('utf-8').decode(event.data) - 若后端发的是 Base64 编码后的二进制（即字符串形式的 Base64），才走上一节流程
- 注意检查
ws.binaryType：设为'arraybuffer'可确保event.data类型稳定
容易被忽略的边界点
实际部署中，最容易翻车的地方不在解码逻辑本身，而在两端编码约定是否一致：
- 后端是否真的用 UTF-8 编码原始文本？Java 默认用平台编码（可能是 GBK），Node.js
Buffer.from(str).toString('base64')默认 UTF-8，但 Pythonbase64.b64encode(s.encode())若没显式传'utf-8'会出问题 - Base64 字符串是否被 URL-safe 处理过？比如把
+换成-、/换成_、省略=——这种必须先还原再atob() - WebSocket 消息是否分片？
event.data可能只是完整 Base64 字符串的一部分，需缓存拼接后再解码
