一个常见的误解
“把密码 Base64 一下就安全了”——这是新手最常犯的错误之一。Base64 看起来像乱码，但它和加密毫无关系：Base64 是编码，不是加密。
本质区别
- 编码：让数据能被安全传输或存储，完全可逆且无需密钥——任何人都能立刻还原原文。
- 加密：让没有密钥的人无法读取，依赖密钥。
- 哈希：单向不可逆，用于验证完整性或存储口令摘要。
Base64 只是把二进制映射成 64 个可打印字符（A-Z、a-z、0-9、+、/），用于在不支持二进制的场景（邮件、URL、JSON）中携带数据。
一眼识别 Base64
- 字符只在 A-Z、a-z、0-9、+、/ 范围内；
- 长度是 4 的倍数：3 字节变 4 字符，体积约增 33%；
- 结尾常见
=或==填充。
该用哪个
在文本协议里携带二进制（图片内联、JWT、附件）→ 用 Base64；需要保密 → 用 AES 等对称加密加随机密钥；要验证“没被改过” → 用 SHA-256 等哈希。三者常组合出现，但互相不能替代。
实战：同一需求到底该用哪个
| 场景 | 该用什么 | 为什么 |
|---|---|---|
| 在 JSON / URL / 邮件里携带二进制 | Base64 | 可逆、无需密钥，只解决“怎么传输” |
| 只有自己人能读 | AES-GCM 等对称加密 | 没有密钥无法解密，还能发现篡改 |
| 校验文件是否被改动 | SHA-256 等哈希 | 单向不可逆，改一位就得到完全不同的摘要 |
| 保存用户口令 | bcrypt / Argon2 | 自带盐值与慢哈希，显著抬高暴力破解成本 |
代码示例
// 浏览器：中文必须先转 UTF-8 字节，否则 btoa 会抛错
const encoded = btoa(String.fromCharCode(...new TextEncoder().encode('中文文本')));
const decoded = new TextDecoder().decode(
Uint8Array.from(atob(encoded), c => c.charCodeAt(0))
);
// Node.js：原生支持 UTF-8，最省心
const b64 = Buffer.from('中文文本', 'utf8').toString('base64');
const back = Buffer.from(b64, 'base64').toString('utf8');三个常见错误
- 把 Base64 当加密：想“藏”密码，但解码只需要一行代码；
- 直接 btoa 中文：btoa 只接受 Latin-1 字符，中文会直接抛异常，必须先转成字节；
- 大文件转 Base64 塞进页面：体积增加约 33%，还会拖慢首屏渲染，超过几 KB 就别内联。
延伸问题
JWT 为什么用 Base64Url？因为标准 Base64 里的 +、/ 在 URL 中会被转义或截断，所以 JWT 把 + 换成 -、/ 换成 _ 并去掉 = 填充。Base64 能压缩数据吗？不能，它反而让数据变大，只是让数据变得“可打印”。
动手试试：Base64 编解码、对称加密、哈希计算
如何向他人讲清这一区别
这个概念争议大，往往不是理解问题，而是表述问题。以下类比在实践中比较好用。
- 信封与保险箱：Base64 像把文件换个信封并贴上标准标签，任何人都能拆开；加密像放进保险箱，没有钥匙打不开。两者解决的是完全不同的问题。
- 通用格式与专属格式：编码是为了让不同系统都能读，属于格式转换；加密是为了让不该读的人读不到，属于访问控制。把格式转换当成访问控制，是把工具用错了方向。
- 验证方式：判断一段数据是否只是编码，只需尝试解码；判断是否加密，则要确认是否持有密钥。这一条最容易被忽视，也最能说明问题。
- 组合才是常态：实际系统常常先用加密保证保密，再用编码保证可传输，最后用哈希或签名保证完整性。分层各司其职，任何一层都不能替代另一层。
组织内的落地建议
在团队规范中明确写出“禁止以编码代替加密”，并在代码评审中把“看起来像乱码”当作可疑信号而非安全证明。同时为真正需要保密的场景提供统一的加密工具与密钥管理流程，让正确做法比错误做法更省力，规范才可能被执行。
在文档与培训中的写法
建议在团队文档里直接给出对照表：目的、是否可逆、是否需要密钥、能否验证完整性。把四项写清后，绝大多数误用会在设计阶段就被发现，而不是等到安全评审时才被指出。对新成员的培训也应覆盖这一条，它属于最基础的概念底线。