带有效access_token调用Google OAuth2接口仍报401缺少认证凭证

既然已经确认持有的access_token本身有效，可按发生概率从高到低定位诱因：

• 最高发问题：后端没正确从请求体拿到access_token的实际值
  你是用JSON请求体把参数传给后端的，最容易踩的坑就是后端取值逻辑和传参结构不匹配：比如后端框架没正确开启JSON请求体解析、错把取值的字段名写成其他值（比如把access_token错配成token/accesstoken）、取值时拿到的是None或空字符串。这种情况下代码里拼出来的Authorization头实际内容是Bearer （后面没有实际token值），Google自然会判定请求缺失认证凭证——这个问题完全不违背“token本身有效”的前提，因为后端压根没把正确的token拼到请求头里。
  快速验证方法：在拼请求头发往Google的代码块里加日志，直接打印最终生成的完整Authorization头内容，和你直接在Postman调Google接口时填的认证头做逐字符对比，差异立刻就能找出来。
• 第二类常见问题：请求头拼接格式不符合OAuth2规范
  比如拼接时不小心把token前后带入了多余的空格、换行符、JSON解析残留的引号；或是漏写了Bearer和token之间的必要空格，导致Google侧无法正确解析头里的token内容，最终判定为无有效认证凭证。
• 第三类隐蔽问题：全局请求配置覆盖了自定义认证头
  如果你用requests库的全局Session对象发请求，且之前给Session配置过全局默认请求头（比如提前设置过空的Authorization、或是其他业务接口用的固定认证值），就会出现全局配置覆盖本次自定义头的情况——最终发出去的请求里根本没有你代码里写的带token的Authorization字段。
• 第四类环境类问题：出口链路拦截了认证头
  如果后端服务所在的网络有出口代理、安全网关，这类设备可能会对出站请求的头做清洗，直接把自定义的Authorization头过滤删除，导致最终到达Google服务器的请求里没有任何认证信息，触发对应报错。

内容的提问来源于stack exchange，提问作者Guilherme Lima