URL-safe Base64：为什么要把 + 和 / 换成 - 和 _

标准 Base64 的字母表里有 + 和 /，这两个字符在 URL 里有自己的含义：+ 在查询字符串里表示空格，/ 是路径分隔符。URL-safe 变体把它们换成 - 和 _，其余 62 个字符完全不变。

替换是唯一的差别

标准：  A-Z a-z 0-9 + /
    URL-safe：A-Z a-z 0-9 - _

只有索引 62 和 63 两个字符换掉了。这意味着同一段数据用两种变体编码，结果只在出现 + 或 / 的位置不同，其余部分逐字相同。

反过来，解码时把 - 换回 +、_ 换回 / 就能用标准解码器处理。这个工具在解码前会自动做这步替换，所以两种变体的输入都能解。

不换会怎样

把标准 Base64 直接放进 URL：

• + 在查询字符串里被服务端解码成空格，字符串内容被改写。
• / 被当成路径分隔符，路由匹配到不存在的路径，直接 404。
• = 填充在某些框架里被当成分隔符。

三种都是「不报错、但数据被改」的故障，排查起来很费时间，所以凡是要进 URL 的 Base64，一律用 URL-safe。

JWT 为什么强制 URL-safe

JWT 的三段（Header、Payload、Signature）都是 Base64URL 编码后用小圆点连接，因为它要能放进 URL、HTTP 头、Cookie 而不需要再次转义。

JWT 还额外规定去掉末尾的等号填充，所以你会看到 eyJhbGciOiJIUzI1NiJ9 这种结尾没有 = 的字符串。解码时按长度补回即可。

还有哪些场景需要

• 文件名：/ 不能出现在文件名里。
• URL 参数：任何要拼进查询串的二进制数据。
• 正则或日志：避免 / 与分隔符冲突。

不需要进 URL 时（比如 JSON 字段、邮件附件），标准 Base64 更通用，兼容的库也更多。