Fetch发起带请求体的GET请求报Unhandled Rejection错误如何解决？

结论先行 #

GET 请求无法携带请求体是浏览器对 fetch/XHR 实现的强制约束，同时也不符合 HTTP 标准规范，没有可用于生产环境的合法绕过方案。

可选解决方案（按推荐优先级排序） #

1. 改用 POST 请求（最推荐） #

这个方案改动成本最低，同时完美满足敏感数据不暴露在 URL 中的安全要求：

• 前端仅需调整 fetch 的 method 字段为"POST"，其余代码无需修改：

if (isAuthenticated){
  console.log("test -----------")
  console.log(user.email)
  fetch("http://###.###.###.###:8080/User/check", {
     method: "POST", 
     headers:{"Content-Type":"application/json"},
     body: JSON.stringify( {
        email: "B.Nye@ABC.uk"
     })
  }).then((result)=> {
    if (result.ok){
      console.log("success")
    } else{
      console.log("fail")
  }})}

• 后端仅需将对应接口的允许请求方法从 GET 调整为 POST，原有校验逻辑完全复用即可。

不用过度纠结“查询操作必须用 GET”的 RESTful 教条，安全优先的场景下用 POST 携带敏感查询参数是行业通用做法。

2. 敏感参数放入自定义请求头（折中方案） #

如果一定要保留 GET 方法，可以把邮箱放入自定义请求头传递，避免出现在 URL 中：

• 前端调整代码如下：

fetch("http://###.###.###.###:8080/User/check", {
  method: "GET",
  headers: {
    "X-User-Email": "B.Nye@ABC.uk"
  }
})

• 后端从请求头中读取X-User-Email字段做校验即可，注意要在跨域配置中允许该自定义头的传递。
  注意：需要确认服务端日志不会存储自定义请求头内容，否则仍有敏感数据泄露风险

3. 参数放入URL查询参数（不推荐） #

如果以上两个方案都无法实现，只能选择将邮箱放入URL查询参数，注意要对特殊字符做编码处理：

fetch(`http://###.###.###.###:8080/User/check?email=${encodeURIComponent("B.Nye@ABC.uk")}`)

该方案的风险是邮箱会明文出现在浏览器历史、服务端访问日志、代理节点日志中，仅可用于非敏感场景，使用时建议先对邮箱做可逆加密后再传输，后端解密后再做校验

不建议尝试的“绕过”方案 #

部分教程提到的修改HTTP包、使用非标准请求方法等hack手段，兼容性极差且不符合规范，生产环境完全无法落地，不要尝试。

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