小猿圈web学习-当fetch遇到302状态码，会发生什么?

随着互联网的发展，出现了越来越多的互联网公司，同时对于web前端开发者的需要也是越来越供不应求，一个好的web开发者更是不容易招聘到，今天呢小猿圈就给大家分享一个我们web工作中的一个小知识点，希望能够帮助到大家。
在用户未登录的时候，后端会返回302状态码，浏览器根据响应头的设置跳转到SSO页面。重定向到正确的登录页面来让用户登录，这似乎并没有什么问题。然而，当我需要用fetch从后端请求一些数据的时候，请求会失败并且重定向并没有发生。
所以，第一个问题是:
我仅仅用koa写了一个小例子来测试fetch的302状态码。在后端，当接口 /bait 接受一个请求，会设置一个302状态码并且在响应头中增加重定向的位置信息：/gotcha。代码如下：
JavaScript

1 1234567891011121314
JavaScript

现在，如果我向 /bait 发起一个请求，/gotcha 会返回响应信息:

检查网络请求发现，第一个请求 /bait 返回了302，然后发起了第二个请求 /gotcha：

所以302是透明的：我们发起请求，后端返回302，然后浏览器会帮助重定向到新的接口，并返回最终的数据。这里的“透明”指，我们可以查看被重定向的接口以及最终返回数据的接口。

这些代码可以在我的 github 上查看，你可以克隆这个仓库并运行这些代码。
下个问题是:
处理这些需要认证的接口最好的方法是什么?
虽然fetch不能拦截302状态码，但是它可以处理401和403状态码。所以可以让接口返回401，响应如下:
JavaScript

1 1234
JavaScript


在大多数情况下，fetch取得的信息会很多，不可能每个人都会考虑这些情况，因此，最好的办法是封装一个公共的方法，把回调函数作为参数，来处理不同的情况。
总结
针对两个问题，总结出两点内容:

1. fetch不能拦截302，浏览器会自动从302响应的头信息的重定向地址中取到数据。
2. 针对认证的情况，后端可以返回401状态码，让前端去检查返回的状态码并据此执行相应操作。
   好了，今天关于小猿圈web学习分享就到这里，如果大家觉得不错的话，记得点个赞哦，也希望大家能够关注我，小猿圈会持续给大家分享一些有用的干货的，谢谢大家。