从Axios到Fetch：前端拦截重定向的探索与实战避坑

1. 为什么前端需要拦截重定向？

在开发视频播放、文件下载等功能时，我们经常会遇到资源地址变更的情况。比如用户点击下载按钮时，后端返回的原始链接可能已经失效，需要通过302重定向到新的地址。这时候如果前端直接使用原始链接，就会导致资源加载失败。

我遇到过这样一个实际案例：某视频平台用户反馈下载功能时好时坏。排查后发现，部分视频资源地址变更后，后端返回302状态码进行重定向。但由于前端播放器直接使用原始链接作为video标签的src，导致在没有实际加载视频前尝试下载时，浏览器无法获取到真实资源地址。

传统解决方案是让用户先播放再下载，但这明显增加了操作步骤。更合理的做法应该是在前端就拦截重定向，自动获取最终资源地址。这就是我们需要研究Axios和Fetch处理重定向机制的原因。

2. Axios处理重定向的机制与局限

2.1 Axios的自动重定向行为

Axios是基于XMLHttpRequest封装的HTTP客户端。在实际使用中，我发现它有一个很重要的特性：默认会自动处理重定向。比如下面这段代码：

javascript复制axios.get('https://example.com/video.mp4')
  .then(response => {
    console.log(response.status); // 200
    console.log(response.headers.location); // undefined
  });

即使服务器返回302状态码，Axios也会自动跟随重定向，最终返回的是重定向后的响应。这就导致我们无法直接获取到重定向前的headers信息，特别是关键的location字段。

2.2 为什么无法关闭自动重定向？

查阅Axios文档时，我发现它确实提供了maxRedirects配置项，但这个配置只在Node.js环境下有效。在浏览器环境中，重定向行为是由XMLHttpRequest底层控制的，Axios无法干预。

深入研究发现，XMLHttpRequest的工作机制是这样的：

1. 浏览器发送初始请求
2. 服务器返回302响应
3. 浏览器自动发起新请求到location指向的地址
4. 最终将重定向后的响应返回给JavaScript

整个过程对开发者