前端调用API更新用户接口时JWT鉴权失败，Postman正常，疑似请求定义错误

问题根源 #

• 跨域预检拦截导致Authorization头丢失：前端发跨域PUT请求时，因为携带自定义的Authorization头，浏览器会先发送OPTIONS预检请求校验权限。当前后端的CORS配置大概率只给POST请求的预检响应配了允许携带Authorization头的规则，漏配了PUT方法的对应规则，导致浏览器判定PUT请求不允许携带Authorization头，实际发请求时直接把这个头删掉了。后端收不到合法Token，自然返回未授权。
  这也能解释为什么Postman调用完全正常、其余接口都能正常校验Token：Postman不受浏览器跨域规则限制，不会触发预检，能正常把Token传给后端；其余接口走POST方法时，CORS已经放行Authorization头，不会出现头丢失的问题。
• 更新用户接口的请求配置本身存在缺陷
  1. Authorization头拼接缺少规范要求的空格：当前写的是`Bearer${getTokenApi()}`，标准格式要求Bearer和Token之间必须有一个空格。虽然现有后端的Token解析逻辑靠字符串切分、去空格的方式兼容了无空格的写法，但这种兼容性很脆弱，后续一旦换成标准JWT校验逻辑，全量接口都会出问题。
  2. 请求体未做序列化、缺少Content-Type头：当前直接把JS对象传给body参数，没有做JSON.stringify()处理，也没在headers里声明Content-Type: application/json，就算解决了授权问题，后端也解析不了请求里的用户更新数据。

修复操作 #

1. 调整后端CORS配置，给所有支持鉴权的请求方法统一配置预检规则，确保OPTIONS响应里包含：
   • Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS
   • Access-Control-Allow-Headers: Content-Type, Authorization
     避免浏览器拦截自定义请求头。
2. 把前端所有接口的Authorization头拼接补上规范要求的空格，改成`Bearer ${getTokenApi()}`。
3. 给updateInfoApi补上和其余正常请求一致的配置：
   • headers里增加"Content-Type": "application/json"声明
   • body参数替换为JSON.stringify(data)，保证请求体是合法JSON字符串。
4. 顺带优化后端的Token解析逻辑，不要靠纯字符串切分提取Token，严格按照Bearer <token>的格式拆分提取，减少解析错误的概率。

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