Google Chrome中使用JavaScript fetch时GET方法自动转为OPTIONS的问题

这个问题其实是CORS预检请求在搞鬼，我来帮你拆解下原因和可行的解决办法：

为什么会出现这种情况？ #

当你的请求包含自定义HTTP头部（比如你代码里的Authorization），Chrome等浏览器会先自动发送一次OPTIONS预检请求，用来确认目标服务器是否允许这种带自定义头部的跨域请求。而Safari的预检缓存机制和Chrome略有不同，所以不会出现这个问题；偶尔刷新页面能正常发GET，是因为浏览器缓存了之前的预检结果，直接跳过了OPTIONS步骤。

具体解决步骤 #

1. 确保服务器正确处理OPTIONS请求 #

这是核心问题，服务器必须在OPTIONS请求的响应中返回正确的CORS头部，示例需要包含的头部如下：

Access-Control-Allow-Origin: 你的前端域名（比如http://localhost:3000，不能用*如果请求带Authorization）
Access-Control-Allow-Methods: GET, POST, OPTIONS
Access-Control-Allow-Headers: Authorization
Access-Control-Max-Age: 86400  # 设置预检结果缓存1天，减少重复OPTIONS请求

只有服务器返回这些头部，浏览器才会继续发送后续的GET请求。

2. 检查前端请求的细节 #

• 你的代码里'Bearer' + token少了个空格！正确的格式应该是'Bearer ' + token（Bearer后面必须加空格），这个小错误可能导致服务器无法识别Authorization头部，进而出现预检通过但GET请求无数据的情况。修改后的代码：

  fetch(BaseURL + type, { 
    method: 'GET', 
    headers: { 'Authorization': 'Bearer ' + token } 
  })
  

• 确认BaseURL + type拼接后的API地址和前端页面域名确实存在跨域情况（不同域名/端口/协议），如果是同域请求不会触发预检。

3. 额外排查点 #

• 打开浏览器开发者工具的Network面板，查看OPTIONS请求的响应头部，确认是否包含了上面提到的CORS头；如果有缺失，需要调整服务器配置。
• 如果是开发环境，检查是否使用了代理工具（比如Webpack Dev Server的proxy），确保代理正确转发了OPTIONS请求到后端服务器。

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