当使用 `fetch` api 与后端交互时，服务器端发起的重定向（如会话失效时跳转登录页）默认只会让 `fetch` 内部跟随并获取新资源，而不会自动触发浏览器页面导航。本文将深入解析 `fetch` api 处理重定向的机制，并提供一种简洁有效的客户端解决方案：通过检查响应的 `redirected` 属性并手动设置 `window.location.href`，确保浏览器在重定向发生时正确跳转到目标页面，从而优化用户体验并避免冗余的前端逻辑。
理解 Fetch API 的重定向行为
在构建现代 Web 应用时，前端通常通过 `fetch` API 与后端进行异步通信。后端在处理某些请求时，例如用户会话过期或未授权访问，可能会尝试通过发送 HTTP 重定向响应（如 `301 Moved Permanently` 或 `302 Found`）来引导客户端跳转到登录页面或错误页面。在 Node.js/Express.js 后端，这通常通过 `res.status(301).redirect("/login.html")` 等方式实现。
然而，许多开发者会发现，尽管浏览器的开发者工具中清晰地显示了服务器发起的重定向以及 `fetch` 请求成功获取了重定向目标页（例如 `login.html`）的内容，但浏览器本身并未自动导航到该页面。这是因为 `fetch` API（以及早期的 `XMLHttpRequest`）的设计初衷是为了进行数据获取，而不是直接控制浏览器窗口的导航。当 `fetch` 遇到重定向响应时，它会默认遵循（`redirect: 'follow'`），并返回最终重定向到的资源的响应，但这个过程是发生在 JavaScript 内部的，不会影响到浏览器地址栏的 URL。
简而言之，`fetch` 成功获取了重定向后的内容，但它不会告诉浏览器“请跳转到这个新的 URL”。这与用户直接在地址栏输入 URL 或点击链接时浏览器自动处理重定向的行为有所不同。
实现浏览器页面跳转的解决方案
为了解决 `fetch` 重定向不触发浏览器导航的问题，我们需要在客户端 JavaScript 代码中显式地处理这种情况。`fetch` API 的响应对象提供了一个非常有用的属性：`response.redirected`。当此属性为 `true` 时，表示请求在处理过程中发生了至少一次重定向。同时，`response.url` 属性将包含最终重定向到的 URL。
因此，我们的解决方案是在 `fetch` 请求的 `.then()` 回调中检查 `response.redirected` 属性，如果为 `true`，则手动将 `window.location.href` 设置为 `response.url`，从而强制浏览器进行页面跳转。
示例代码
以下是一个实现此逻辑的示例：
fetch('/api/protected-data', {
method: 'GET',
headers: {
'Content-Type': 'application/json'
}
})
.then(response => {
// 检查响应是否经过重定向
if (response.redirected) {
// 如果是重定向，则手动将浏览器导航到重定向的目标URL
window.location.href = response.url;
// 返回一个Promise.reject()或直接return，阻止后续的.then()执行
// 或者根据业务逻辑决定是否继续处理
return Promise.reject('Redirected, navigating to new page.');
}
// 如果没有重定向，则正常处理响应
if (!response.ok) {
throw new Error(`HTTP error! status: ${response.status}`);
}
return response.json();
})
.then(data => {
// 处理正常的数据响应
console.log('Data:', data);
})
.catch(error => {
// 处理错误，包括重定向时的Promise.reject()
console.error('Fetch error:', error);
// 可以在这里进一步处理非重定向的错误，例如显示错误消息
});
在这个示例中，当服务器返回一个重定向响应（例如 `302 /login.html`），`fetch` 会跟随这个重定向并获取 `login.html` 的内容。此时 `response.redirected` 将为 `true`，`response.url` 将是 `http://yourdomain.com/login.html`。我们的代码会检测到这一点，并将 `window.location.href` 设置为 `response.url`，从而实现浏览器向 `/login.html` 的跳转。
最佳实践与注意事项
1. 全局重定向处理
为了避免在每个 `fetch` 调用中重复相同的重定向检查逻辑，强烈建议封装 `fetch` 或创建一个全局的请求拦截器。这样可以集中处理所有请求的重定向逻辑，提高代码的可维护性和一致性。
async function customFetch(url, options) {
try {
const response = await fetch(url, options);
if (response.redirected) {
window.location.href = response.url;
// 在这里抛出错误或返回一个特殊的Promise，以阻止后续处理
throw new Error('Redirect handled, navigating...');
}
if (!response.ok) {
// 可以在这里统一处理非重定向的HTTP错误
const errorData = await response.json().catch(() => ({ message: 'Unknown error' }));
throw new Error(`HTTP error! status: ${response.status}, message: ${errorData.message}`);
}
return response; // 返回原始响应，以便后续链式调用
} catch (error) {
console.error('Custom fetch error:', error);
throw error; // 重新抛出错误，让调用者处理
}
}
// 使用封装后的 fetch
customFetch('/api/some-resource')
.then(response => response.json())
.then(data => console.log(data))
.catch(error => {
if (error.message !== 'Redirect handled, navigating...') {
// 处理其他错误
console.error('Application specific error:', error);
}
});
2. HTTP 状态码的选择
服务器在发送重定向响应时，应根据实际情况选择合适的 HTTP 状态码。对于会话过期或未授权访问导致需要跳转到登录页的情况，通常更适合使用 `302 Found`、`303 See Other` 或 `307 Temporary Redirect`。`301 Moved Permanently` 通常用于资源永久性移动，可能会被浏览器缓存，导致不必要的副作用。
3. 用户体验考量
在某些情况下，如果重定向是预期的行为（例如，用户点击了一个需要登录才能访问的链接），在跳转前可以考虑给用户一个短暂的提示，或者确保跳转过程足够流畅，避免给用户带来突兀的感觉。
总结
通过 `fetch` API 进行异步请求时，服务器端发起的重定向并不会自动触发浏览器页面导航。为了实现无缝的用户体验，开发者需要在客户端代码中主动检测 `response.redirected` 属性，并结合 `window.location.href = response.url` 来手动引导浏览器进行页面跳转。通过封装 `fetch` 请求或使用全局拦截器，可以优雅地管理这一逻辑，确保应用的健壮性和可维护性。
