什么时候不该用 Base64：性能、安全与设计上的取舍

开发者很容易顺手就用上 Base64，因为几乎每种语言都能一行代码完成编解码。这份便利会让它看起来像是搬文件、存二进制块、藏数据的万能方案。可现实是，它只把一个很窄的问题解决得很好：用文本来表示字节。一旦超出这个范围，它往往只增加成本，却不创造价值。

别把 Base64 当加密用

编码过的数据不等于受保护的数据。Base64 不需要任何密码或密钥，而且字符特征足够明显，工具常常会自动识别并解码。凭据、访问令牌、个人信息、内部标识符，对任何能读到这串编码的人来说，依然完全暴露。

如果在意机密性，请使用成熟的加密方案并做好密钥管理；如果在意完整性，请使用数字签名或消息认证码；如果要存储密码，请使用专门设计得很慢、能抵抗猜测的密码哈希函数。Base64 也许会出现在这些输出周围——因为密文或哈希有时需要文本表示——但它只是最外层的包装纸。

把一张小图片放进 JSON 响应有时很实用，尤其当这个值必须留在同一份自包含文档里时。但对大文档、音频或视频这么做通常就是糟糕的设计。Base64 会让载荷膨胀约三分之一，JSON 解析器得持有并处理一个超长字符串，应用还可能为编码和解码两份副本各分配一次内存。

二进制上传、multipart 表单、流式响应和对象存储，才更适合大文件。它们让两端能够增量处理数据、保留内容类型，避免把每个字节都过一遍中间文本形式。接口完全可以只返回元数据和一个带签名的下载 URL，而不是把整个文件内嵌进去。

文本列之所以诱人，是因为方便肉眼检查，但用它存二进制值效率很低。编码形式占用更多存储、增大备份体积，还可能和文本排序规则或索引产生别扭的相互作用。数据库提供二进制列类型，恰恰就是为了让任意字节无需经过文本转换即可存放。

对于大体积资产，把文件存在关系型数据库之外往往更好。数据库可以保留归属关系、校验和、尺寸和存储键，而由对象存储去承载字节本身。最终怎么选取决于一致性和运维需求，但 Base64 几乎不会让任何选项变得更好。

data URL 把内容直接嵌进页面或样式表，常常用的就是 Base64。它省掉一次网络请求，对极小且不变的资产有帮助。但它也让资源无法被单独缓存，撑大了承载它的文档，还让源文件更难阅读。改一个图标，就得让整份 CSS 或 HTML 失效重来。

现代 HTTP 连接能高效处理大量小请求，所以"把每个资产都内联"的老建议早已不再普遍成立。请实测页面的真实表现：极小的装饰性图标也许是合适的候选，而照片或整套字体通常都不是。

Base64 能成功解码，只证明这串字符在某个变体下可以被解释成字节，并不能证明这些字节是一张安全的图片、一份有效的证书，或者就是发送方声称的那种文件类型。攻击者编码恶意内容，和编码正常内容一样轻而易举。

应用应当在昂贵处理之前就限制解码后的大小，在合适时检查文件签名，用可信解析器校验格式，并把不可信文件存放在远离可执行路径的地方。如果大小限制只加在编码字符串上，就必须把编码与解码大小的关系也算进去。

分层系统有时会因为某个组件期望文本而编码一次，又因为另一个组件不知道前一次变换已经发生而再编码一次。接收方解码一次，得到的却是另一串 Base64。双重编码进一步增大体积，也模糊了真正的契约。

清晰的字段命名、规范文档和边界测试能预防这个问题。一个字段应当说明它装的是原始文本、标准 Base64、Base64URL，还是完整的 data URL。编码应当只发生在确实需要的那道边界上，解码则在跨过边界后立即进行。

上面这些取舍并不意味着 Base64 是坏东西。对于纯文本格式里的小段二进制值、邮件附件、PEM 文档、紧凑令牌，以及那些既有契约本就要求它的接口，它依然可靠，简单和普遍支持都是真实优势。

真正的设计问题是：接收系统需要文本还是字节。能接受字节时就直接发字节；只认文本的通道挡在中间时，Base64 才是实用的适配器。有意识地使用它，能让开销始终可见，也避免一个兼容性工具沦为多余的架构习惯。