刚入行那会儿我特别不能理解一件事为什么我敲localhost:8080就能打开页面敲localhost:8080/foo就给我一个 404后来带我的前辈听了这个问题冲我一笑反问了一句你先搞清楚这两个地址分别是谁来响应的。这一问直接把我问进了路由这个话题里。前端路由和后端路由这两个词听起来都带路由却是两种完全不同的东西。很多新人栽跟头不是栽在代码上而是栽在没搞懂它俩分别管什么。这篇我打算用讲人话的方式把前端路由和后端路由掰开揉碎说清楚包括它们各自怎么工作、本质区别、典型踩坑以及实际项目里到底该用哪种。1. 路由到底在路什么先看一张地图1.1 拆开路由这两个字路由路由其实就是路和由。路就是 URL 地址由就是走向、去处。合在一起路由就是一件事根据地址栏里那一串 URL找到它对应的内容。这句话听起来像废话但路由的全部秘密都藏在这里。关键问题是这个查找动作发生在哪里发生在服务器上就是后端路由。发生在浏览器里的 JS 里就是前端路由。举个例子地址栏敲进https://example.com/about同样是这个地址后端路由和前端路由的处理方式完全不一样。后端路由的思路是浏览器把这个地址发给服务器服务器翻自己的地址簿找到/about这个条目返回一个对应的 HTML 文件。浏览器拿到新文档从头到尾渲染一遍。前端路由的思路是浏览器里的 JS 代码早就下载好了它自己维护着地址对应哪个组件的映射表。当地址栏变成/aboutJS 收到变化通知直接在页面里卸载掉旧组件、挂载上关于我们组件。全程没有新的页面请求页面本身根本没有刷新。对用户来说地址栏看起来都是/about但背后的走向完全不同。这就是很多人第一次搞混的根源同一个 URL在不同路由体系里是被不同角色处理的。1.2 一张类比图餐厅领位员和家庭聚餐后端路由比较像餐厅领位员。你报一个桌号领位员对照手里的桌号表带你走到固定的餐桌。那张桌子是真实存在的你走过去需要时间路上可能还会撞到别的客人。对应到网页上就是切换页面要等网络请求、页面刷新、白屏一下。前端路由更像是在自己家里请客。客人说去书房看看你根本不用出门推开客厅旁边那扇书房的门就行。大门一直没开人始终在同一栋房子里只是从一个房间走到了另一个房间。对应到网页上就是页面不刷新组件原地替换屏幕内容变了但整页文档没重新加载。这个类比基本能解释两者绝大多数差异要不要走大门发请求、要不要换房子刷新文档、瞬间切换和隔一段时间到达。后面的内容都是围绕这个核心差别展开的。2. 后端路由服务器手里那份地址簿怎么工作2.1 传统网站的页面长什么样十年前的主流网站基本是一个 URL 对应一个物理文件的思路。/about对应about.html/blog/index.html对应一个博客列表页。你访问的每一个地址服务器都能在磁盘上找到对应的 HTML 文件直接读出来返回给你。这种做法在最早期的静态网站里特别直观前端和后端、页面路径和服务器目录几乎是同一个东西。后来动态网站出现了URL 不再严格对应磁盘文件而是由服务器代码做一次分发但整体思路没变接到请求匹配路径返回内容。2.2 一次点击背后的完整链条假设你在传统网站上点了一个关于我们的链接链路是这样的浏览器发现一个a href/about开始发起新的 HTTP 请求。请求到达服务器服务器解析请求行里的路径/about。服务器拿着这个路径去查自己的路由表看该交给哪个函数处理。处理函数返回对应的 HTML 内容服务器把它装进响应体。浏览器收到完整的 HTML 文档整个页面重新渲染。每一步都有网络开销和时间成本尤其在第二步到第五步之间用户看到的是地址栏在转圈、页面一片空白。网速差的时候那种断档感非常明显这也是传统多页应用体验上最大的痛点。2.3 用一小段代码看清后端路由为了让你看代码时不陌生我用 Node.js 的 Express 框架写一段最基础的后端路由const express require(express); const app express(); app.get(/, (req, res) { res.send(h1首页/h1); }); app.get(/about, (req, res) { res.send(h1关于我们/h1); }); app.get(/user/:id, (req, res) { res.send(用户详情${req.params.id}); }); app.listen(3000);这里面的app.get(/about, ...)就是在定义服务器的一张路由表当收到的请求方法为 GET、路径为/about时执行后面的回调函数把h1关于我们/h1作为响应返回。注意/user/:id这种写法id是动态参数。也就是说/user/1和/user/999都能命中同一个路由服务器不用为每个用户单独写一个处理函数。这就是后端路由最典型的形态位置固定、处理函数复用、参数从 URL 里取。2.4 后端路由的取舍得放在真实场景里看后端路由从来没有被淘汰因为它在两个维度上有不可替代的优势首屏快服务器直接把 HTML 吐给浏览器用户不用等一堆 JS 先下载完才看到内容。SEO 友好搜索引擎的爬虫拿到的是完整 HTML标题、正文、链接全在里面不用执行 JavaScript 就能抓取内容。安全边界清楚权限校验、数据校验都放在服务端前端只是显示层。它的代价也很明确每次切换页面都要重新请求整个 HTML网络传输量大白屏等待时间明显。页面状态在切换时基本归零存到 URL parameter 里也很别扭交互体验断断续续。前后端耦合重页面骨架和路由逻辑混在服务端改动一处可能要连带调整一堆模板。我以前维护过一个用后端路由做的老系统每次点菜单等两三秒白屏是常态。后来部分页面改成 Ajax 局部刷新体验才好一点。那个阶段其实已经在往前端路由的方向靠了。3. 前端路由浏览器里自己演的一出换场戏3.1 为什么前端路由会诞生单页应用SPA的出现是前端路由的直接推动力。SPA 想解决的问题很明确把整个应用包装成一份 JS 下发到浏览器运行时由前端代码控制界面不再每次让服务器重新发一份 HTML。但这里有个矛盾用户改变视图时地址栏地址如果不变就没法收藏、分享、刷新后定位到当前页面。所以前端必须要有一套地址跟着内容走的机制。前端路由就是为这个需求服务的它本质上是一段运行在浏览器里的逻辑维护一组URL 路径 - 组件的映射。3.2 hash 模式最朴素的那套锚点魔法前端路由最古老的实现是 hash 模式。URL 里#后面的部分叫 hash例如https://example.com/#/about。hash 有一个特性改变它不会触发浏览器发请求。#后面的内容本来就是用来做页面内锚点定位的浏览器允许你随便改。因此早期前端路由的玩法就是页面加载时读取location.hash比如#/about。JS 把页面里对应组件渲染出来。用户点击链接切换hash时监听hashchange事件。事件触发后重新解析新的 hash切换组件。简化的伪代码大概是window.addEventListener(hashchange, () { const route location.hash.replace(/^#\//, ); renderRoute(route); // 根据路径渲染不同组件 });hash 模式最明显的好处是简单、兼容性好、不依赖服务器配合。哪怕发布在静态服务器上用户刷新#/about也只是刷新页面本身服务器返回的还是那一个index.htmlJS 再根据 hash 重新渲染正确的内容不会 404。它的代价也很直接URL 里多个#不好看产品经理和运营同事往往会来跟你争取能不能把那个井号去掉而且爬虫抓取时对 hash 后的部分基本不看重SEO 上吃亏。3.3 history 模式现代框架的默认选择后来 HTML5 提供了 History API主要是pushState和replaceState两个方法。它们可以在不刷新页面的前提下修改地址栏 URL同时浏览器会记录历史栈。现代框架如 Vue Router、React Router 都默认使用 history 模式。比如在 React Router 里你可以用createBrowserRouter声明路由表const router createBrowserRouter([ { path: /, element: Home / }, { path: /about, element: About / }, { path: /user/:id, element: UserDetail / }, ]);这里path就是路由匹配路径element就是对应要渲染的组件。浏览器把/about这样的地址展示出来URL 干净、自然、看不出用了前端路由。但 history 模式有个大坑也是所有新人几乎都会撞上的直接刷新或手动输入深层地址时会出现 404。原因在于pushState只改变了地址栏并没有真的向服务器请求/about。这个地址对服务器来说是虚拟的。当你点击链接从首页跳转到/about没问题因为整个过程由前端控制但如果你在/about页面按一下 F5 刷新浏览器会真的把https://example.com/about作为一个 HTTP 请求发给服务器。服务器没有这个物理文件也没有匹配到后端路由于是返回 404。解决办法是让服务器做一次兜底所有匹配不到静态资源的路径都返回index.html也就是把请求交还给前端路由去处理。部署在 Nginx 上的常见配置是location / { try_files $uri $uri/ /index.html; }这句话的意思是先找真实存在的文件找到就返回找不到就统一返回根目录的index.html。这样前端路由就能在浏览器里接管地址解析。3.4 为什么前端路由可以换内容不刷新很多新人会困惑不刷新页面内容是怎么变的答案很简单因为界面本来就是 JS 控制的。你在浏览器里拿到的是一个已经加载完毕的应用框架视图从首页切换到关于我们本质上只是修改了某个容器节点里的 DOM 结构或者触发了一次视图重新渲染。页面没有重新加载所以不会白屏JS 的全局状态也全部保留着。数据如果是从接口拿的前端路由切换时通常只发起数据请求可能是一个 JSON也可能是一小段 HTML但不会是整个页面文档。对网络负担小很多交互上能做到秒开。这也是 SPA 体验好的核心原因。4. 一张表看穿它俩的本质差异4.1 核心维度对照我整理了一张非常直白的对照表建议你收藏起来面试前看看也管用维度后端路由前端路由映射表存在哪服务器代码里浏览器 JS 运行时谁负责解析地址服务器前端框架地址变化时响应发起全新 HTTP 请求JS 监听地址变化局部渲染切换页面是否刷新整页刷新不刷新每次网络传输内容整个 HTML 文档通常只有 JSON 数据首屏加载速度快服务器直接返回偏慢需先下载应用 JSSEO 表现天然友好hash 不友好history 需要额外方案部署要求无特殊要求history 模式需服务端 fallback真实安全边界服务端可控前端拦截只是 UI 层面4.2 同一个 URL两侧的理解完全不同/about这个路径后端路由看到的是一个查询键服务器要拿着它去文件系统或者业务代码里找对应的内容找到之后吐一个完整页面。前端路由看到的是一个匹配条件框架会根据它找到对应的组件然后就地渲染。这意味着同样一个地址在两套体系里含义和生命周期都不一样。你不能说用了前端路由后端就不用处理路径了。实际上只要是 history 模式服务器仍然要处理所有前端定义的路径——只是它统一把路径转发给入口 HTML而不是分别映射到不同文件。4.3 最容易混淆的页面路由 vs 接口路由这是新手最容易混的点很多人以为后端路由指的就是接口路由跟前端路由是一对一的对应关系。不是的。一个前端页面路由 A对应的后端接口可能是 B、C、D 三个。比如你在页面/dashboard上页面本身渲染的是仪表盘组件这个组件却会同时请求/api/user/info、/api/statistics/list好几个接口。页面路由决定你看什么界面接口路由决定数据从哪来它是两套独立的映射表。我把这个观念纠正过来之后再回头看很多问题就清楚了。比如本地开发时配代理你要配的是接口路由那一层而不是页面路由那一层后端联调时 404你要排查的也是接口路由而不是抱怨前端路由怎么没生效。5. 新人最常踩的 5 个坑附完整排查链路5.1 坑一history 模式上线后直接访问子页面 404这是前端路由领域排名第一的踩坑现场。现象是本地开发一切正常点击导航跳转也没问题但代码部署到服务器之后用户从首页点进去的详情页一刷新就 404或者把链接直接发给朋友对方打开也是 404。排查链路是这样的先在本地复现如果本地开发环境npm run dev访问/detail/123没问题说明前端路由本身是好的。登录服务器用curl -I https://你的域名/detail/123看返回状态码如果返回 404基本可以断定是服务器层没兜底。查看服务器日志确认这个请求确实被打到了磁盘查找逻辑上没有落到项目入口 HTML。打开 Nginx 配置看根 location 有没有try_files。解决办法就是上面提到的那行配置try_files $uri $uri/ /index.html;。修改后记得nginx -s reload再刷新就正常了。这个坑之所以容易踩是因为很多人只学了前端框架手册根本不知道 history 模式还有服务端配合的要求。部署知识在这里就成了必不可少的环节。你要是用了BrowserRouter就要时刻记住你的地址对服务器来说是虚拟的服务器得学会把认不出的路径都交给前端。5.2 坑二hash 模式的链接又丑又不方便分享如果你选择了 hash 模式那 URL 会是https://example.com/#/about。这种链接在内部跑起来没问题但一旦要发给别人问题就来了很多第三方平台在做链接解析时对#后面的内容不敏感可能在微信、短信里展开的预览信息抓不到你想要的页面描述。合作伙伴给你回传一个地址复制的时候容易多出一截#导致路径对不上。产品经理会跟你说这个井号能不能去掉因为对外推广的链接都希望干净。这个问题的本质是hash 模式在 URL 美观度 和 服务端零配置 之间选择了后者。如果项目是内部工具、管理系统hash 没毛病如果是对外宣传、需要分享跳转的页面尽量用 history同时把服务器 fallback 配好。5.3 坑三前端路由路径和接口路径撞车我见过一个项目前端路由配置了/user/list作为用户管理页同时后端接口也是/user/list。上线后发现用户点进用户管理页页面白屏控制台报了一个组件找不到的错误。原因是开发环境的代理把所有/user/list都转发给了后端前端路由压根没机会渲染组件。或者反过来某些请求被前端路由拦截当成页面处理结果组件不存在。排查链路在浏览器 Network 面板里看请求类型如果发现一个页面访问被记录成了 XHR/接口请求说明匹配到的是接口路径。检查前端路由表的 path 是否和接口前缀重叠。统一规划命名空间前端页面路径用/user/list后端接口统一加/api前缀变成/api/user/list。这不是什么高技术含量的问题纯粹是命名空间没规划造成的。但只要项目一大了没人提前约定迟早会碰上一次。我的经验是后端接口一律加版本号或前缀比如/api/v1/...前端页面路由不要以/api开头。这一条约定能省掉很多无意义的排查时间。5.4 坑四以为路由守卫就是安全性前端路由里有一种东西叫路由守卫比如 Vue Router 的beforeEachReact Router 的loader或中间件可以在进入某个页面之前做登录校验、角色权限校验。很多新人以为加了守卫系统就安全了。实际情况是前端路由守卫只负责用户体验不负责安全。原因很简单前端所有代码都在用户的浏览器里用户打开开发者工具就能看到所有逻辑、改掉所有逻辑。你写的if (!isAdmin) redirect只拦住了正常操作的普通用户拦不住一个直接在地址栏输入接口地址、直接发请求的有心人。我的排查经历是有一个内部后台路由守卫拦住了非管理员访问/admin结果测试同学直接在控制台里调用了后端的管理员接口数据照样返回。原因是后端接口没有做对应的权限校验。这个问题的修复也简单后端每个敏感接口都必须校验登录态和角色前端路由守卫可以留着但它的定位只能是引导和提示真正能不能拿到数据必须由接口层决定。这条坑值得反复强调前端路由是做界面后端路由做权限两者不能互相替代。5.5 坑五刷新页面之后状态全丢了前端路由不刷新页面所以在页面之间跳转时内存里的状态、数据、滚动位置都能保留。但一旦用户按下 F5整个页面重新加载JS 的内存被清空各种状态回到初始值。用户会感觉怎么我明明选中了筛选条件、打开了某个 Tab一刷新全没了排查链路不复杂Network 面板里能看到刷新时浏览器重新请求了首页文档。框架的全局状态比如 Vuex/Pinia、Redux是存在内存里的内存一清就归零。想保留状态要么把关键信息同步到 URL query 中比如/list?page2statusopen要么放进localStorage/sessionStorage要么提交到服务端。我强烈建议优先把状态放到 URL query 里。因为这样刷新之后地址栏本身就带参数用户复制链接发给别人别人打开也是同样的视图。这个体验比本地存储更自然也更利于分享。只有不适合暴露在地址栏的临时数据才考虑本地存储。6. 我的选型建议别再一刀切6.1 内容型网站后端路由或服务端渲染更省心博客、官网、文档站、营销活动页这类网站的核心诉求是能被搜索引擎搜到、首屏快点、分享出去不丢人。这种场景下后端路由天然占优或者直接用服务端渲染SSR方案框架把首屏 HTML 在服务端拼好再返回前端接管后续路由。技术选型上内容站不要为了显得现代强行上纯前端渲染的 SPA。SEO 和内容抓取的隐性成本往往比开发时省下的那几秒钟要贵得多。6.2 后台管理系统前端路由 history 是主流后台系统用户都是登录后才用的不需要被爬虫收录也不在意首屏多加载一两秒。它的体验核心是操作连贯、状态保留、响应快这正好是前端路由的强项。这种场景我推荐 history 模式加服务端 fallback因为内部系统也不适合输出一串#给同事。部署阶段把 Nginx 的try_files配好后面基本不会有刷新 404 的问题。后端接口照常独立部署只做数据交互不做页面返回。6.3 混合玩法服务端吐首屏前端接管后续还有一种常见形态是首页着陆页用后端路由直接输出登录进去后的应用区全部由前端路由接管。这样既有 SEO 和首屏体验又保留 SPA 的方便。这种混合方案在大型站点里很常见本质上是对钱花在哪一段的取舍。服务端渲染首屏往往需要多搭一层渲染服务复杂度会上升所以小团队项目不一定有必要上。记住一个原则工程复杂度是随着收益增加的没有收益就不要提前引入。6.4 给新人的一张行动清单如果你看完这篇还是觉得有点绕我建议直接做三个小实验做完全懂了用 Express 写两个页面路由启动服务后在浏览器里点击跳转打开开发者工具的 Network 面板观察每一次跳转都发起了新的文档请求。把一个 Vue 或 React 项目切到 hash 模式点击切换后再切到 history 模式分别在详情页按 F5 刷新一次对比地址栏变化和页面是否 404。把 history 模式部署到服务器并配置try_files再刷新一次体会服务端兜底到底兜的是什么。亲手把这三个流程走一遍比背十遍概念都有用。最后再分享一个我的个人经验带新人时我一般不会让他直接背前端路由 vs 后端路由的定义而是让他复述一遍我上面说的第一个故事——地址栏里敲了个地址这个地址由谁来响应。能把这句话说清楚前端路由和后端路由的区别就算彻底装进他自己脑子里了。