btoa() 直接处理中文、emoji 或重音字符（如 "héllo"）会立即抛出 domexception 错误，因其仅支持 latin-1（码点 0–255）单字节字符，而 javascript 字符串为 utf-16 编码，多字节 unicode 字符天然越界，无法执行。
直接用 btoa() 处理中文、emoji 或带重音的字母（如 "héllo"）会立即报错，不是乱码，而是根本执行不了——因为 btoa 只认 Latin-1 字符（码点 0–255），而 JavaScript 字符串是 UTF-16 编码，多字节字符天然越界。
为什么原生 btoa/atob 无法处理中文
btoa() 内部把字符串当作单字节序列处理，每个字符必须对应一个 0–255 的字节值。中文在 UTF-16 中至少占 2 个码元（如 "你" 是 \u4f60），远超 Latin-1 范围，所以调用 btoa("你好") 必然抛出 DOMException。这不是兼容性问题，是设计限制。
- 纯 ASCII 字符（如
"hello"、"token123"）可直用btoa - 含中文、日文、emoji、é/ñ/ü 等 Unicode 字符，必须前置转换
- 错误示例：
btoa("café")同样失败，因é是 Unicode 字符
安全编码：先 encodeURIComponent，再 btoa
把原始字符串转成百分号编码（URI 编码），得到全 ASCII 字符串，btoa 就能顺利接手。这个过程不改变语义，只是“转述”为浏览器可接受的格式。
- 正确写法：
btoa(encodeURIComponent(str)) - 示例：
btoa(encodeURIComponent("你好"))→"JUU0JUJEJUEwJUU1JUFEJUE3" - 别用
escape()：已废弃，对+、/、space处理不一致，易出错 - 注意：URI 编码本身不是 Base64，不能替代；此组合专为满足 Base64 协议要求（如 JWT、Basic Auth payload）而设
安全解码：先 atob，再 decodeURIComponent
atob() 解出来的是一串 URI 编码格式的字符串（如 "%E4%BD%A0%E5%A5%BD"），还不是可读文本，必须用 decodeURIComponent() 还原。
- 正确顺序：
decodeURIComponent(atob(encodedStr)) - 顺序颠倒（如
atob(decodeURIComponent(...))）会因格式不匹配而返回空或报错 - 建议解码前
.trim()：服务端返回的 Base64 常含换行、空格或前后空白 - 校验 Base64 格式：可用正则
/^[A-Za-z0-9+/]*={0,2}$/.test(str)初筛，避免无效输入触发异常
大文本与现代替代方案
这套 URI + Base64 组合在 IE10+ 和所有现代浏览器稳定可用，但有隐含成本：两次字符串转换对长内容（如 >100KB JSON）有明显性能开销。
- Node.js 环境推荐：
Buffer.from(str, 'utf8').toString('base64')，一步到位 - 前端高性能需求：可用
TextEncoder+Uint8Array+ 自定义 Base64 表，但实现复杂度高 - 重要提醒：Base64 不是加密！敏感数据（密码、token）不可依赖它保密，仅用于编码/传输
