面试官问「Base64 能保护数据吗」：90% 候选人都答错了

先说结论：Base64 不是加密，一秒钟都不是。它没有任何密钥，任何人拿到 Base64 字符串都能瞬间还原原文。SGVsbG8= 是什么？把 Hello 喂给任何一个在线工具就能得到。可即便如此，我依然在安全审计中见过把「用户密码 Base64 一下再存库」的系统。

一个真实翻车故事

某创业公司的「安全方案」：前端把 API 密钥 Base64 编码后放在请求头里，团队坚信「看不懂就是安全」。攻击者用浏览器 DevTools 打开 Network 面板，看到 Authorization: Basic cGFzczEyMzQ1Ng==，粘贴到解码工具，明文密码当场社死。整个过程不到十秒。

这类事故的根源不是技术难度，而是概念混淆。下面把最容易搞混的五组场景一次理清。

混淆一：编码 ≠ 加密

编码（Base64、URL encoding、hex）是公开的格式转换，目的是让数据能安全通过某个「通道」——比如邮件系统只支持文本，或 URL 里不能出现特殊字符。加密（AES、RSA）需要密钥，没有密钥就拿不到原文。判断标准很简单：有没有密钥？没有，就是编码。

混淆二：哈希 ≠ 加密

哈希（MD5、SHA-256）是单向的，原文无法从哈希值还原。它的用途是校验完整性、存密码摘要——注意，存密码要用 bcrypt/Argon2 这类专用算法并加盐，而不是裸 SHA-256。把「MD5 一下」当加密，是上个时代遗留的坏习惯，彩虹表分分钟教做人。

混淆三：Base64 ≠ 压缩

有人以为 Base64「把数据变短了」，恰恰相反：它会把体积膨胀约 33%。三个字节变成四个字符。它的价值是「可打印、可传输」，不是省空间。真正压缩请用 gzip/zstd，两者经常配合使用——先压缩再编码，顺序别反。

混淆四：URL 编码 ≠ Base64

JWT 是重灾区。JWT 的三段式结构用的是 Base64URL，不是标准 Base64——因为标准 Base64 里的 + 和 / 在 URL 中有特殊含义。同理，encodeURIComponent 和 encodeURI 也各有分工：前者会转义 ? 和 &，用于编码参数值；后者不会。用错一个，参数就丢了。

混淆五：对称加密 ≠ 非对称加密

AES 对称加密快，适合加密大量数据，但密钥怎么安全地给对方？RSA 等非对称算法解决了密钥分发问题，却慢得没法加密大文件。所以现实方案是混合加密：用 RSA 传 AES 密钥，用 AES 加密数据本体。TLS 握手就是这个套路。

一张速查表

• Base64 / hex：格式转换，无安全性，随时可逆
• gzip：压体积，无安全性
• SHA-256：单向校验，不可逆，不能「解密」
• bcrypt / Argon2：密码存储专用
• AES：对称加密，快，需管好密钥
• RSA / ECC：非对称加密，密钥交换与签名

下次面试被问到「Base64 是加密吗」，你可以自信地反问一句：「您是想考察编码传输，还是密钥体系？」——这一问，通常比答案本身更能加分。