Base64 经常被用来把二进制数据放进文本环境里，比如邮件、JSON 字段、网页里的小图片、接口调试时的文件内容。
它解决的问题不是压缩，而是“让二进制内容用一组安全的可打印字符表示”。所以看到 Base64 后的字符串变长，不是异常，而是它的编码方式决定的结果。
Base64 到底在做什么
普通二进制数据按字节组织，一个字节是 8 bit。Base64 的思路是把连续的二进制位重新分组：
- 每次取 3 个字节，也就是 24 bit。
- 把这 24 bit 拆成 4 组，每组 6 bit。
- 每组 6 bit 可以表示
0到63，刚好对应 64 个可打印字符。 - 用字符表把这 4 个数字映射成 4 个字符。
可以简单记成：
3 字节 = 24 bit
24 bit = 4 组 * 6 bit
4 组 6 bit -> 4 个 Base64 字符这也是名字里 64 的来源：每个编码字符承载的是 64 种可能之一。
为什么 3 字节会变成 4 字符
从“信息量”角度看，3 个字节是 24 bit，拆成 4 个 6 bit 后仍然是 24 bit，看起来并没有多。
但问题在于，Base64 的结果通常要作为文本字符串存储或传输。每个 Base64 字符在常见 ASCII / UTF-8 文本里也要占 1 个字节。
所以实际存储时会变成：
原始数据：3 字节
Base64 后：4 个字符，通常占 4 字节这就带来了典型的体积膨胀：
4 / 3 = 1.333...也就是大约增加 33%。
不足 3 字节时为什么会有等号
Base64 每次按 3 字节一组处理，但真实数据长度不一定刚好是 3 的倍数。
如果最后只剩 1 个字节，就没有足够的 24 bit。编码器会补齐缺失的位，再在输出末尾加两个 =，表示这里有两个字节是补出来的。
如果最后只剩 2 个字节，就补 1 个字节，并在末尾加一个 =。
所以常见结尾规律是：
剩 1 字节 -> 输出末尾常见 ==
剩 2 字节 -> 输出末尾常见 =
刚好 3 的倍数 -> 通常没有 == 不是原始内容的一部分，它是 padding 标记，方便解码时知道最后一组应该还原多少真实字节。
Base64 不是压缩
Base64 很容易被误解成“编码后更方便，所以也许更小”。实际正好相反，它通常会变大。
它的价值主要在这些场景：
- 文本协议里需要安全承载二进制数据。
- 某些系统只接受可打印字符，不方便直接传原始字节。
- 需要把小文件、小图片或签名数据临时放进 JSON、HTML、配置或日志里。
如果目标是减小体积，应该先考虑压缩算法，比如 gzip、zstd、brotli。Base64 可以和压缩配合，但它本身不负责压缩。
工程上什么时候要小心
Base64 适合小块数据和协议适配，不适合把大文件长期塞进数据库文本字段或接口 JSON。
原因很直接：
- 体积会膨胀约 33%。
- 字符串解析会带来额外内存占用。
- 大对象进入日志、消息队列或数据库字段后，排查和传输都会变重。
- 前后端或服务间如果频繁做 encode/decode，会增加 CPU 成本。
如果是图片、附件、视频这类内容，更稳妥的方式通常是对象存储或文件服务，只在业务数据里保存 URL、对象 key、哈希、大小和 MIME 类型。
小结
Base64 的核心不是神秘算法，而是一次重新分组：
3 个 8 bit 字节 -> 4 个 6 bit 编码单元 -> 4 个可打印字符它让二进制数据能安全进入文本环境，但代价是体积通常增加约三分之一。
所以判断要不要用 Base64 时，先问清楚：现在的问题是“文本环境里传二进制”，还是“想让数据更小”。前者可以用 Base64，后者就该看压缩和存储方案。
