把「Hi」做 Base64 得到 SGk=：两个字节凭空变成四个字符，末尾还缀着一个装饰性的等号。要是这算加密，那密文比明文长、又不需要任何钥匙、谁都能还原——没有哪种加密敢这么设计。Base64 的真实身份低得多：一种转写格式，专门让二进制数据平安穿过那些「只认打印字符」的系统，比如邮件附件和网页里的 data: URI。
它解决的是传输问题，不是安全问题
早期邮件协议只允许 7 位可打印 ASCII 字符过境，图片、程序里那些高位字节可能被中转服务器剥掉或替换。Base64 的思路：挑一套到处都安全的 64 个字符——A 到 Z、a 到 z、0 到 9，再加 + 和 /。64 恰好是 2 的 6 次方，于是每个字符能装载 6 位信息，任何二进制数据都能按 6 位一组重新排队、查表拼写。整个过程没有密钥，也没有信息被藏起来，截获者读它就像读换了字体的明文。
4/3 的膨胀率：从 8 位挤进 6 位
膨胀的账很清楚：原来每字节装 8 位，编码后每字符只装 6 位，同样的信息量需要 8/6=4/3 倍的字符，体积上涨 33.3%。按组算更直观：每 3 字节共 24 位，拆成 4 组各 6 位，3 进 4 出，比例 4:3。一个 1024 字节的文件 Base64 之后约 1366 个字符；文件越小、越是凑不满 3 字节的尾巴，padding 的存在感越强。
拿「Hi」手工算一遍
H 的 ASCII 码是 72，二进制 01001000；i 是 105，二进制 01101001；拼成 16 位串 0100100001101001。从左按 6 位切：第一组 010010 等于 18，查表得 S；第二组 000110 等于 6，得 G；剩下 4 位 1001 补两个 0 成 100100，等于 36，落在小写区间的第 11 个字母，即 k。最后一组本来就是补出来的，空位用一个 = 占坑，最终 SGk=。补位规则：原始字节数除 3 余 1 补两个 =，余 2 补一个 =。
它和加密的真正分工
加密的定义性要求是「不知道密钥就算不出原文」，Base64 只要求「运输层不嫌弃非 ASCII」。同一输入永远得到同一输出，不引入任何随机性，信息的熵一比特没少。真要保护内容得靠 AES 这类算法，Base64 通常站在包装环节：把加密后的二进制密文转成能贴进配置文件和 URL 的文本。网页链接场景还会用 URL-safe 变体，把 + 和 / 换成 - 和 _，免得和查询参数里的老符号撞车。
用进制转换养出数感
Base64 的本质是 256 进制与 64 进制之间的换算，再往下就是 2 进制。想亲手核对上面的 6 位分组，可以打开 进制转换工具：把 72 转成二进制看 01001000，把 18 转成二进制看 010010，膨胀比 4/3 与补位逻辑全部来自这一一对应。看懂它，也就顺手看懂了为什么 JWT 明文可读、为什么内嵌图片的请求头长得离谱。