膨胀率的算法
Base64 每 3 字节输出 4 个字符，因此理论膨胀率是 4/3，约为 33.3%；不足 3 字节的尾部还要补填充，短内容相对开销更大。例如 100 字节输入输出 136 个字符（含填充），1MB 二进制编码后约 1.37MB 文本。此外如果编码结果被换行折行存储，还要加上换行开销。理解这个比例有助于在接口设计阶段判断「内联还是分通道」。
基本信息
| 理论膨胀 | 4/3，约 33.3% |
|---|---|
| 计算方式 | 输出长度 = 向上取整到 4 的倍数(输入长度 × 4 / 3) |
| 短内容影响 | 尾部填充对极小内容的相对开销更高 |
| 附加开销 | 换行折行、缩进、包裹标记等 |
| 内存影响 | 编解码过程通常需要在内存中持有原文与编码后两份数据 |
| 决策建议 | 大文件走二进制通道，小对象才内联 |
典型使用场景
- 接口设计：评估把图片或文件放进 JSON 字段带来的带宽与内存成本
- 数据库容量规划：Base64 列比原始二进制列多占约三分之一空间
- 缓存与消息队列：膨胀后的报文可能触及大小上限
- 日志与审计：把二进制编码进日志会显著放大日志量
- 传输方案选型：小图标内联能减少请求，大文件内联则得不偿失
膨胀率验证
膨胀率验证
# 验证固定比例：不同长度下的输出大小
python -c "import base64; [print(n, len(base64.b64encode(b'x'*n))) for n in (1, 2, 3, 4, 6, 100, 1000)]"
# 与可压缩文本对比：压缩后再编码通常优于直接编码
python -c "import base64, zlib; d=b'x'*1000; print(len(base64.b64encode(d)), len(base64.b64encode(zlib.compress(d))))"
# 容器内实际增量估算（含换行的 PEM 文本）
python -c "import base64; d=open('/dev/urandom','rb').read(1024); e=base64.b64encode(d); print(len(d), len(e), round(len(e)/len(d),3))"
# 方案选择：超过阈值改用二进制字段或分片上传常见规模的膨胀
| 原始大小 | 编码后（约） | 适用判断 |
|---|---|---|
| 1 字节 | 4 字符 | 开销比例最高，仅适合标记类数据 |
| 100 字节 | 136 字符 | 内联到 JSON 通常可接受 |
| 10 KB | 约 13.3 KB | 需评估接口大小限制 |
| 1 MB | 约 1.37 MB | 建议改走二进制通道 |
| 100 MB | 约 137 MB | 必须分片或专用通道，否则内存与超时风险高 |
膨胀不是唯一成本：编解码要在内存中保留两份数据，大对象还会带来垃圾回收压力与超时风险。评估时应同时看带宽、内存峰值与单次请求时长，而不是只看比例。
压缩后再编码并非总是更优：压缩对随机二进制几乎无效，反而增加一次计算开销与格式复杂度。对已压缩的媒体文件（图片、视频）不要再套压缩，直接走二进制通道。
容量规划要按最坏情况算：接口上限、消息队列单条上限、数据库列长度都按「原始大小 × 4/3 再留余量」估算，避免上线后出现大对象写入失败的间歇性问题。