为何有Base64URL？
OAuth 回调里 state 参数、OIDC 的 fragment、JWT 的第二与第三段，底层都常用 Base64URL：把加号斜杠换成横线与下划线，padding 还可能省略，因此拿着「标准 Base64 工具」永远解不开。联调最容易发生网关把加号变成空格、把斜杠当路径切开的事故。在线 Base64URL 编解码帮市场与项目经理与研发对齐「同一套字母表」，避免周五晚上还在吵到底是哪一侧粘错。和 Postman 自动解码对照时，记得拆 JWT 的点分三段再逐段处理。把 Base64URL 写进对接 checklist，能抵消一半无效返工。对埋点里 URL 携带的长串，也要先确认是不是 Base64URL 再决定是否需要二次 URI 编码。
如何在 JWT 与 OAuth 场景下正确使用 Base64URL 编解码
- 从 Authorization 头或 JWT 中复制时，先按点号切成三段，只对第二、三段做 Base64URL 解码，不要把整串含点号一起丢进解码器。
- 在页面选择是否保留填充符；若对端库配置为 no-padding，你应在联调表里写明，并在单元测试里用同一配置 round-trip，避免生产与测试各用一半规则。
- 把解码出的 JSON 与发行方文档比对 iss、aud、scope 等声明；若要把 URL 参数再拼进浏览器地址栏，仍可能要做 percent-encode，别把 Base64URL 当成「已经 URL 安全」的免死金牌。
Base64URL 常见问题
我把 JWT payload 用标准 Base64 解码失败，换成 Base64URL 立刻成功，这是否说明签发方实现不标准？
不说明对方错了，RFC7519 明确规定 JWT 各段使用 Base64URL；若你混用标准表，加号与斜杠在 HTTP 传输里极易被改写。应以 JWT 规范为准更新内部工具链，而不是要求 IdP 改成传统 Base64。
state 参数里塞了 Base64URL 的 JSON，浏览器重定向后服务端说签名不匹配，这通常是编码问题还是 state 被中间代理改写了？
应先抓包核对 query 串是否被解码再编码导致双重变换；同时确认服务端用相同字符集解析 JSON。把 state 设计得尽量短，减少被日志系统截断的概率，并在错误页打印哈希而非原文。
Go 的 RawURLEncoding 与 Java 的 Base64.getUrlEncoder 输出尾部等号不一致，团队应以谁为准写进接口文档？
应以消费者语言库默认行为为准并在文档附样例；若跨语言混用，可统一约定「无 padding」并在解码端开启宽松模式，但要在安全评审里记录宽松可能带来的误判风险。
我想把 Base64URL 串直接粘进 Markdown 链接里分享，有没有字符还需要额外转义才能不破坏渲染？
Markdown 对括号与下划线有语法含义，长串应放进反引号代码段或上传 gist；在 IM 里分享时也要避免被表情与自动链接识别截断，最好用文件或短链承载原串。
移动端 WebView 里从剪贴板读取的 JWT 段前后多了不可见空格，导致 Base64URL 解码随机失败，有什么工程化规避办法？
在客户端统一做 trim 与正则校验字符集，再调用解码；日志里打印长度与首尾字符 hex 而不是全文。对关键登录链路应在原生层保存令牌，避免依赖剪贴板这一易污染通道。