Bearer 容易错哪？
从Chrome DevTools、Postman或curl日志复制Authorization时，常见坑是整段粘成`Bearer Bearer eyJ...`、前后多了不可见换行、HTTP/2伪头混剪、或把`Basic`与`Bearer`搞混。OAuth2与RFC6750规定资源请求应携带`Authorization: Bearer <JWT>`，多一个空格有时被严格解析器拒绝，少一个点则根本不是合法JWS。用能剥离Bearer前缀并清洗空白与引号的在线JWT解码流程，先把「格式问题」与「令牌内容问题」拆开：前者秒修，后者才需要查exp、aud与签名。对要同时给研发与客户发复现步骤的白领，这一步能显著减少群里无意义的来回粘贴。移动端从系统分享复制时，授权头常被加多余引号或截断，先粘到备忘录核对长度，比反复质疑后端是否正常更快。集成文档应附「单行可复制示例」与「禁止事项」，避免即时通讯软件吞掉反斜杠导致整段失效。驻场同学若先帮客户把Bearer格式理顺，满意度回访里专业度评分往往更高。网关若同时接受Cookie与会话头，复制错面板也会白忙，先确认抓的是真正命中资源请求的那一行。
如何从Authorization头规范提取Bearer JWT并在工具里一次解码成功
- 在Network面板点开具体API请求，复制Request Headers里的Authorization整行；若使用Swagger UI，注意不要复制示例里的尖括号或markdown反引号，只保留`Bearer`后第一个非空字符开始到行尾或空格前的JWT本体。
- 粘贴前在纯文本编辑器检查是否被邮件客户端自动折行、是否夹带`Cookie`或`Digest`片段；若网关要求`DPoP`或`MTLS`，确认你拿的是资源访问令牌而不是mTLS证书绑定失败时的错误页HTML。
- 解码成功后把Header里的alg与Payload里的iss、aud、exp抄进工单模板，并注明复制来源（浏览器版本、是否HTTP/2）；若仍401，再附网关trace id，避免对方继续怀疑Bearer格式。
Bearer 常见问题
联调第一天就卡在粘贴上，我把`Authorization: Bearer eyJ...`整行粘进解码框却提示非法字符，这种把协议关键字一起粘进去的低级错误该怎么一眼自查并写进团队防呆清单？
多数解码器只接受裸JWT或可选Bearer前缀；若工具未自动剥离，请手动删除`Authorization:`与大小写混合的`bearer`关键字，仅保留点分三段。可用正则`eyJ[^\s]+\.[^\s]+\.[^\s]+`快速抽取，避免肉眼漏掉行首隐藏BOM。
移动端抓包看到`Bearer`后紧跟换行再跟第二段Base64，怀疑中间人篡改，这种分断是工具显示问题还是真被注入？
先在十六进制视图确认是否仅为显示折行；若字节里真插入0x0A，则令牌已被破坏需重新签发。对比同一请求在服务端日志中的Authorization长度与哈希，可快速判断是客户端展示问题还是链路污染。
网关同时支持`Authorization`与`X-Access-Token`两种传法，我复制了后者但研发坚持要前者，这种双通道兼容在联调文档里该怎么写死规范？
应以OAuth2资源服务器实现为准写死单一传参，并在网关拒绝时返回明确error code；双通道只在迁移窗口短期存在并需监控弃用指标。把「只认Authorization Bearer」写进集成测试，避免新接入方继续抄旧博客里的非标准头。
我们担心新人照抄旧模板会反复踩坑，Postman自动在Bearer Token页加了`Bearer`前缀，我又在Headers里手写一遍导致双重前缀，这种重复该在团队模板与代码评审清单里如何防呆？
应统一使用环境变量注入裸JWT到Authorization头，或在Pre-request Script里拼接；代码评审把「手写Bearer + UI Bearer」列为常见缺陷清单。新人培训演示一次双重前缀的401抓包，比文档里加粗更有效。
我带Windows同事照文档跑演示却连续401，curl示例写成`-H "Authorization: Bearer $TOKEN"`但在CMD里变量展开失败，这种跨平台复制问题会不会被误判为令牌本身已损坏？
CMD与PowerShell引号规则不同会导致整行被截断；应在文档提供PowerShell专用示例并附`echo %TOKEN%`长度校验步骤。若解码器提示长度异常，先核对shell展开是否成功，再谈令牌本身。