当使用 `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; // 重新抛出错误，让调用者处理 }}// 使用封装后的 fetchcustomFetch('/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` 请求或使用全局拦截器，可以优雅地管理这一逻辑，确保应用的健壮性和可维护性。
以上就是Fetch API 与服务器端重定向：实现浏览器页面跳转的正确姿势的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1530577.html
微信扫一扫 
支付宝扫一扫 
