前端路由可以和后端路由一起组合使用吗？

一般要么用前端的要么用后端的吧...

你说的是单页面应用吧，第一次必须走服务器，后续的就不用了，浏览器就可以控制了

没有绕过后端服务器，有效，后端路由优先前端路由，后端要配置重定向到 index 前端路由才生效，这是 history 模式。hash 模式也是一样就是

这个要看你的部署机制。如果是分开部署，想让前端路由生效，nginx 本来就要进行设置，肯定不会走后端。如果是先后端解析再把页面当作模板返回，那就是后端路由为主了，这种情况下需要后端的 controller 设置一下通配符，把未定义路由统一交给前端解析。

@cw2k13as 后端配置重定向到 index 之后的话，前端还能收到原始的 url 路径吗？ 感觉有点懵

@James369 默认就是请求后端路由，然后后端没有路由会导致 404，用 nginx 把 404 的直接重定向到 index，前端就能收到路由事件变更，这是单页应用程序的规则。另一种就是 hash 模式，hash 模式直接被浏览器当做一个标记跳转不会触发资源请求，所以服务器也收不到任何事件。

前端路由不刷新网页

@James369 只是重定向了，路径没变，index 可以解析到

最近刚好在看前端路由库源码（ react-router 依赖的前端路由库 history ），核心原理大致如下：

１.Browser History：调用浏览器内置对象 history 的 pushState/replaceState，可以做到更改 document.URL 而不重载页面（重发请求）的效果，document.URL 就是地址栏中显示的地址，也是发送请求时 referrer 首部的值，通过监听浏览器事件 popState/hashChange 来监听前端路由的变化，路由改变时执行所有通过 listen 注册进来的回调；

2.Hash History : 基本和 1 中一样，只是 1 中是以整个 URL 做路由管理，这里则是以 URL 的以部分（片段标识符，Hash ）做路由管理，hash 的改变（直接给 location.hash 赋值）同样不会导致页面重载，监听 hashChange 来执行 listen 注册进来的回调；

前端路由还有重要的一点，就是对不同资源的请求（资源路径不同），必须要返回同一个 HTML 文件，因为 F5，Ctrl+F5，刷新按钮等行为会导致页面重载，重新向地址栏中的 URL 发送请求，如果响应个 404 或者其他页面就有点尴尬了。。。

在浏览器里输入地址再回车，一定是先到后端路由再回前端，前端代码初始化后才能拦截路由的

一般用了前端路由就不会在 nginx 上设置路由了吧……
通过前后分离的方式，前端路由控制切换切面，然后根据需要展示的内容向后端发起请求，除了初次加载以外，前后端的传输内容只有具体数据。

前端可以拦截直接输入 url 的情况（ service worker
但是第一次访问肯定不行，所以如果是基于路径的话还是得后端配合）

前后端两个路由全部都生效

所以需要都进行设置

确实很麻烦, 所以才需要框架之类工具减少重复

简单的说就是：
前端渲染页面的路由是服务于挂载点 baseUrl 之后静态页面导航，后端路由是负责(含)baseUrl 之前的所有动态路由导航。

如果一个域名就只有一个单页面应用，那么可以用 hash 或者拦截 path 变化来实现路由。如果希望一个域名用不同 path 来 host 多个单页面应用，可以用只用 hash 。

混合使用理论上也可以实现，但是得看具体什么需求，多数情况下为了方便管理和维护，还是建议使用一套方案。

前端路由有两种模式，一种 hash 和 history
hash 改变请求不会发到后端
history 就是正常请求，所以需要 nginx 重定向到 index.html

@molvqingtai 什么叫 history 是正常请求，正因为 history 的 pushState 不会刷新页面的同时修改 url，所以才能用来做前端路由。在此模式下，刷新网页必须要后端支持返回 index.html