Base64 大小估算器

Base64 用 64 个字符表示每 6 位数据：3 字节（24 位）→ 4 字符，膨胀率恰好 4/3 ≈ 133.33%。末尾不足 3 字节的部分用 = 填充：余 1 字节出 2 字符 + ==，余 2 字节出 3 字符 + =。精确公式：输出字符数 = 4 × ⌈n/3⌉。加上 JSON 转义（data URI 场景）或 MIME 每 76 字符插入的 CRLF 换行（邮件场景，额外约 2.6%），实际开销略高于 4/3。

工程决策的含义：小图标内联进 CSS（data URI）省了 HTTP 请求，但 ① 体积 +33% ② 失去独立缓存与并行下载 ③ 阻塞 CSS 解析——HTTP/2 多路复用普及后，行业共识是「内联阈值 ≤ 2-4KB」。邮件附件强制 Base64（MIME），所以 25MB 附件限制实际只能装约 18.75MB 原始文件。本工具同时给出三种口径的估算：纯 Base64、MIME 换行版、data URI 版。

Base64 膨胀率恒为 4/3（133%），这是由 6 位分组编码决定的数学下限，任何 Base64 变体都无法突破。但实际文件膨胀会略高于 133%：不同变体的填充字符、换行符、以及可选的无填充模式（URL-safe 的 - _ 可去掉末尾 =）都会微调体积。对大文件，更多人改用二进制格式（Buffer/ArrayBuffer）或压缩+编码组合：先 gzip 再 Base64，膨胀 33% 往往能被压缩率抵消，整体反而更小。

判断是否需要 Base64 是个工程权衡题：图片/插件这类体积大的资源走 URL 引用（独立请求、可缓存、可 CDN）永远优于内联；只有小到「一次请求的开销 > 内联体积收益」时才内联——经验阈值是 2–4KB。跨语言传递二进制（前端上传、后端解析）Base64 最通用，但替代路径是 FormData 直接发送二进制或 Blob，省去编解码损耗。对长度敏感的场景（如数据库 VARCHAR 列、URL 参数、存储配额），先用本计算器算准膨胀后体积，再做合理规划。