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：它是一层为了让数据能安全穿过文本通道而做的包装，不提供任何保密性，并且要为这层包装付出约三分之一的体积代价。想清楚这两点，大部分相关的问题都能自己定位。
