Base64 大概是所有编码里「用法人人都会、原理少有人讲清」的典型。大多数人第一次接触它是在传图片或者调接口时照着抄一行代码就完事了等到某天发现上传的体积莫名超标、或者某段字符串解不开才开始回头问它到底在干什么。先给结论Base64不是加密不是压缩它只是把二进制数据改写成一串「安全字符」代价是体积增加约三分之一。一、它解决的是什么问题很多通道只保证能安全传输「可打印字符」。典型的例子是早期邮件协议 SMTP以及各种基于文本的配置格式、JSON、XML、URL 查询参数。它们的共同点是遇到控制字符、换行、高位字节就可能被截断、被转义、或者被中间环节改写。而图片、压缩包、密钥这类数据本质上是一堆任意字节几乎必然包含这些「危险」字节。Base64 的作用就是把这堆任意字节重新编码成一串只由 64 个安全字符组成的文本让它能安全穿过这些通道。这 64 个字符是A-Z、a-z、0-9加上和/共 64 个。二、为什么恰好膨胀 33%Base64 的编码单位是3 个字节。3 个字节是 24 位。把这 24 位按每 6 位重新切分正好得到4 组。每组 6 位能表示 0 到 63刚好对应上面那 64 个字符中的一个。于是编码结果的长度就是每 3 字节的输入产出 4 字节的输出。4 ÷ 3 ≈ 1.333也就是增加约 33%。这个数字不是随便定的它是「用 6 位对齐而不是 8 位对齐」带来的必然代价。剩下的部分要分两种情况输入长度是 3 的倍数干净利落没有多余填充。输入长度不是 3 的倍数末尾不足 3 字节用补齐。不足 1 字节补不足 2 字节补。所以常见长度计算公式是编码后长度 4 × ⌈原始长度 ÷ 3⌉而反推原始长度时要注意末尾的数量决定了减去多少原始长度 编码长度 ÷ 4 × 3 −的个数这个公式在实际排查中很有用。比如接口报「内容超过 1MB」你可以先拿编码后长度倒推真实体积判断到底是原文件大还是编码撑大了。三、几个真实踩过的坑坑一把它当加密用。这是最危险的一条。Base64 是可逆的、没有密钥的任何人拿到字符串都能还原。把密码、密钥、身份证号做一次 Base64 再传输安全性和明文没有区别——甚至更糟因为它给人一种「已经处理过了」的错觉。它只解决「能不能传」不解决「谁能看」。坑二在 URL 里直接用标准 Base64。标准 Base64 的字符集包含和/这两个字符在 URL 里有特殊含义放进查询参数会被解析或截断。URL 场景要用URL-safe 变体把换成-/换成_并且通常去掉末尾的填充。顺带说去填充是安全的因为填充只用于对齐不承载信息。但反过来要小心如果接收方按「必须有填充」来解析去掉填充就会失败。这类问题在跨系统对接时特别常见两端约定不一致一个用标准、一个用 URL-safe报错信息还往往只有「解析失败」四个字。坑三换行符导致解析失败。早期规范要求 Base64 每 76 个字符插入一个换行至今仍有不少库默认这么做。于是常见的一幕是字符串复制出来看着没问题程序一解析就报错原因是中间藏了换行或者回车。排查时应该先检查有没有\r、\n、空格这些不可见字符再去怀疑内容本身。坑四把图片直接内嵌进页面或接口。把小图标做成 data URI 内嵌确实能省一次请求但要记住基数是 33% 的膨胀再叠加字符集升级带来的额外增长实际增幅会更大。图标这类小文件还好如果是几百 KB 的图片内嵌之后不仅体积变大还会拖慢首屏解析得不偿失。坑五以为编码后的长度就是文件大小。在一些上传限制严格的服务里编码后的长度才是被校验的那个值。一个 800KB 的文件编码后可能已经超过 1MB 的限额。做这类对接时正确做法是先按公式估算或者直接用工具算一遍而不是传上去等报错。四、怎么快速验证排查这类问题时最省事的办法是把字符串丢进一个编码/解码工具里跑一遍看清楚三件事能不能解开、解开后是多少字节、有没有多余的换行和填充。比如 Base64 编码工具 这类离线小工具可以把编解码和长度核对放在一起做完不用为了看一个长度去写临时脚本尤其是「来回验一遍数据有没有被改动」这种需求编解码对跑一次比读代码快得多。一句话记住 Base64它是一层为了让数据能安全穿过文本通道而做的包装不提供任何保密性并且要为这层包装付出约三分之一的体积代价。想清楚这两点大部分相关的问题都能自己定位。