Vue Router的fallback是干啥用的？怎么配置才对？

terry 8小时前阅读数 10 #Vue

咱在开发Vue单页应用（SPA）的时候，经常会碰到路由相关的问题，比如页面刷新后404、旧浏览器里路由直接“罢工”这些情况，这时候Vue Router里的fallback配置就成了关键角色——可它到底是干啥的？怎么用才能解决实际问题？今天就把这些事儿掰碎了聊聊。

fallback是Vue Router里的啥配置？

先从Vue Router的路由模式说起，Vue Router支持两种常用的前端路由模式：hash模式和history模式。

hash模式用的是URL里的（比如https://xxx.com/#/about），后面的路径变化不会触发浏览器向服务端发请求，前端自己就能处理路由；而history模式基于HTML5的History API，路径更“干净”（比如https://xxx.com/about），但需要浏览器支持history.pushState这类API，还得服务端配合配置。

而fallback是history模式下的一个“兜底”配置，它是个布尔值（默认是true），作用是：当浏览器不支持History API时（比如超旧的IE浏览器），自动回退到hash模式，保证路由功能不失效，简单说，就是让项目在旧浏览器里也能“勉强跑起来”，不至于直接崩掉。

啥时候得关注fallback？

不是所有项目都需要纠结fallback，得看场景：

兼容旧浏览器的项目

如果做的是面向政企、传统行业的项目，用户可能还在用IE9甚至更旧的浏览器（虽然现在越来越少，但确实存在），这些旧浏览器压根不支持History API，要是强行用history模式，路由直接“瘫掉”——页面跳转没反应、刷新就404，这时候打开fallback，Vue Router会自动切到hash模式，至少能保证基本的路由功能能用。

测试兼容性的场景

开发时想验证“旧浏览器下路由是否能工作”，可以主动配置fallback，再用工具模拟旧浏览器环境（比如用虚拟机装旧版Windows+IE，或者浏览器的兼容模式），看看路由是不是自动变成hash模式，以此确认兼容性处理是否到位。

区分“客户端兼容”和“服务端部署”问题

很多人会把“部署后刷新404”和fallback搞混——部署后刷新404是服务端没配置路由重定向（比如nginx没设try_files），得让服务端把所有请求指向index.html；而fallback是客户端层面处理“浏览器不支持History API”的情况，两者完全是不同层面的问题，后面会详细讲。

怎么正确配置fallback？

在Vue Router中，fallback是通过createWebHistory（对应history模式）的配置项来设置的，先看基本写法：

import { createRouter, createWebHistory } from 'vue-router'
const router = createRouter({
  history: createWebHistory({
    fallback: true // 或false，默认是true
  }),
  routes: [/* 你的路由规则 */]
})

配置逻辑很简单：

如果项目需要兼容旧浏览器（比如要支持IE9），保持fallback: true（默认值），让Vue Router自动处理兼容性切换；
如果确定用户都用现代浏览器（比如内部系统，全员Chrome最新版），可以设为false，减少不必要的兼容逻辑（虽然性能影响极小，但代码更简洁）。

配置后怎么验证是否生效？举个例子：在IE9环境下打开项目，看URL里有没有——如果有，说明已经自动切到hash模式，fallback生效了；现代浏览器里URL没，说明用的是history模式，也没问题。

fallback和服务端路由配置有关系吗？

一句话总结：没关系，但得分清两者的职责。

fallback是客户端的“降级策略”：当浏览器不支持History API时，前端自己切到hash模式，这时候hash模式下，服务端只需要返回index.html就行（因为hash不会传给服务端）；

而服务端配置（比如nginx的try_files）是解决SPA刷新404：因为history模式下，浏览器会把完整路径发给服务端，服务端如果没对应的路由，就会返回404，这时候得让服务端把所有请求重定向到index.html，让前端路由接管。

举个栗子：如果项目用了history模式+fallback: true，部署到nginx时，还是得配try_files $uri $uri/ /index.html;——因为现代浏览器用history模式时，刷新页面会触发服务端请求，必须靠服务端配置兜底；而旧浏览器用hash模式时，刷新不会触发服务端的路由请求（因为hash在前端），所以服务端配置主要是给history模式兜底的。

常见误区：fallback能解决部署后的404吗？

很多新手会误以为“打开fallback就能解决部署后刷新404”，这其实是把客户端兼容和服务端配置搞混了。

再强调一遍：部署后刷新404的本质是服务端没有处理前端路由，比如用户访问https://xxx.com/about（history模式），刷新时浏览器会向服务端请求/about，但服务端根本没有这个路由，所以返回404，这时候必须靠服务端配置（如nginx、Apache的重写规则）让所有请求指向index.html，和fallback半毛钱关系没有。

fallback只负责“浏览器不支持History API时，前端自动切hash模式”，解决的是旧浏览器里路由无法工作的问题，和服务端是否返回404完全是两码事。

实战：用fallback处理旧浏览器兼容

假设现在要做一个企业官网,产品经理要求“必须兼容IE9”（虽然很反人类，但甲方需求得满足），这时候怎么用fallback？

配置Vue Router

保持fallback: true（默认），路由模式用history：

const router = createRouter({
  history: createWebHistory({ fallback: true }),
  routes: [
    { path: '/', component: Home },
    { path: '/about', component: About },
    // 其他路由...
  ]
})

测试旧浏览器

找个IE9环境（比如用虚拟机装Windows 7+IE9），访问项目：

如果URL里出现（比如http://xxx.com/#/about），说明fallback生效，自动切到hash模式；
页面跳转、刷新都正常，说明路由功能在旧浏览器里能工作。

如果是现代浏览器（Chrome、Edge等），URL里没有，用的是history模式，路径更美观，体验也更好。

服务端仍需配置

就算开了fallback，部署到生产环境时，服务端（比如nginx）还是得配路由重定向，避免现代浏览器用history模式时刷新404，配置参考：

server {
  listen 80;
  server_name your-domain.com;
  root /path/to/your/dist;
  location / {
    try_files $uri $uri/ /index.html; # 关键配置：所有请求回退到index.html
  }
}

要不要把fallback默认打开？

看项目需求：

公网项目（面向普通用户）：建议保持默认（true），毕竟你猜不到用户用啥浏览器，万一有旧设备访问，至少路由能工作；
内部系统（用户浏览器可控）：比如公司内部系统，全员用Chrome最新版，可以设为false，既能享受history模式的“干净路径”，又能减少代码里的兼容逻辑，让项目更简洁。

fallback是Vue Router给咱的一个“兼容性保险”——不用怕旧浏览器拖后腿，也不用为了兼容放弃history模式的美观，只要搞清楚它的作用、配置方式，再结合服务端部署，就能让路由在各种环境下稳如老狗～