前端跳转谁来做？

• 資深大佬 : drydiy

  这前端直接处理就可以了。

• 主 資深大佬 : pmispig

  @drydiy 我把完整的 js 实现代码都写好粘贴发给他了…

• 資深大佬 : GDC

  个人习惯在后端（服务端）做，因为在前端做 需要加载页面后才执行，用户体验不好。
  另外从 SEO 角度来说也应该服务端做（如果原地址不使用了）

• 資深大佬 : madewocao

  看你们关系好不好，工作量大不大

• 資深大佬 : 90d0n

  看谁嗓门大

• 資深大佬 : retanoj

  这种打一架就行

• 資深大佬 : mxT52CRuqR6o5

  如果是 js 用 history api 做跳转，性能和 nginx302 应该差不多

• 主 資深大佬 : pmispig

  @GDC 如果考虑到体验就不应该做这个跳转，因为这个跳转是 vue 同一个页面，指向同一个 index.html 和同一个视图,好像是为了解决 ie 的一个刷新页面丢失 #后面的参数的问题…
  我也不知道这种骚操作哪里来的

• 資深大佬 : DelayNoMore

  前端 redirect 不就可以了吗？

• 資深大佬 : keepeye

  单页的话前端做

• 資深大佬 : q8164305

  单页前端做，很简单，就一个 redict 配置就行了啊

• 資深大佬 : langjun

  结合上
  SPA：前端合理，
  MPA：前端做会在前端多增加一次网络请求，用户体验不好

• 資深大佬 : GDC

  @pmispig 对噢，如果你要考虑 # 后面的部分，那只能前端做，因为 # 后的参数是不会发送到服务端的，服务端也没法准确跳转（只能跳到新地址的首页去了）

• 主 資深大佬 : pmispig

  @GDC 对。。你提醒了我，这个只能在前端做，服务器 get 不到 #后面的参数。。

• 資深大佬 : heiheidewo

  不管从哪方面讲都是后台做好啊：用户体验 和 SEO。
  除非你想偷懒

• 主 資深大佬 : pmispig

  @heiheidewo 从部署的角度来讲，我希望程序是完全自己独立的，按照一般标准就能跑起来，最讨厌要配这个配那个

• 資深大佬 : geekdocs

  后端直接跳，不解释。

• 資深大佬 : Xusually

  emmm….带了 hashtag，nginx 拿不到 啊，怎么跳

• 資深大佬 : zzzmh

  如果是整站 SPA，就前端了，我是后端也学了 vue cli，这个用 vue-router 跳一跳美滋滋，还不刷新页面，不占用服务器算力

• 資深大佬 : hronro

  你们 nginx 的配置难道不是前端在写吗？

• 資深大佬 : geekdocs

  nginx rewrite 模块

• 資深大佬 : geekdocs

  如果是分离且用了前端路由，可以让前端跳。

• 資深大佬 : wee911

  看具体情况，http://abc.com/xxoo#happy 这个错误链接说导致的谁处理， 前端自己不可能产生一个不存在的路由，大概率历史原因或者后端造成的。
• 資深大佬 : chairuosen

  如果前端部署在根目录,并且是业务跳转比如 /跳 /login，前端做。
  如果前端部署在二级子目录或者非业务跳转，比如活动短网址，ngxin 做。

• 資深大佬 : jkmf

  后端咋判断？#后的内容后端是拿不到的

• 資深大佬 : shintendo

  为什么都说是 spa 内跳转……这不改的是 hash 前面的路径吗

• 資深大佬 : zhgg0

  如果是因为历史遗留，就这一种情况，我个人觉得配 ngnix 302 比较合理。

• 資深大佬 : sm0king

  那个~~ 不担心白屏怎么做都可以。

• 資深大佬 : DL9412

  这个又有 path 又有 hash 的，总不能是用户自己输的吧，直接去把跳过来的地方改掉不就好了

• 資深大佬 : Idealyouth

  nginx 上做啊

• 資深大佬 : Idealyouth

  @q8164305 是很简单，但是没必要

• 主 資深大佬 : pmispig

  @DL9412 我觉得你这种才是真办法，奈何无法沟通这个啊。。。不过只能按他们说的来，他们说啥就是啥

• 資深大佬 : Sapp

  为什么要跳转？ 直接通过路由指向同一个组件不就行了么？

• 資深大佬 : Zach369

  我现在的态度是: 能自己做的就自己做….懒得吵

• 資深大佬 : imswing

  你们说的前端 redirect 是啥。。。。

• 資深大佬 : maple3142

  https://stackoverflow.com/a/5915350/6885801
  在新的瀏覽器上面的 302 redirect 是會自動保留 hash 的

• 資深大佬 : Torpedo

  应该服务端做。上说 hash 的，这个场景根本不影响。
  现在是把一个 url 映射到另一个，必然是服务端做。
  要是前端做了，那会先访问一个 html，然后执行 js，才会跳转。
  服务端做，第一时间就能跳过去

• 資深大佬 : rioshikelong121

  我感觉不应该在前端做。这种规则尽量不要写在代码里面，不然变更的话还得重新发布，放在 nginx 上配置我感觉更灵活一点。

• 資深大佬 : KuroNekoFan

  前端做就前端做吧，不碍事

• 資深大佬 : KuroNekoFan

  之前看过一条微博，说新浪微博的某个跳转之前是 302redirect，后来改成页面 location.href 了
  或许可以这么说：由前端来实现是更实用主义的做法

• 資深大佬 : buffgek

  听产品经理的. 他让谁改 谁就改.

• 資深大佬 : elekids

  Nginx 做跳转，不解释

• 資深大佬 : xderam

  看需求 常用的跟业务无关的可以酌情做几个 不然后患无情 业务变更走不了代码 ci cd 流程 变成了运维变更 时间和风险系数都会变大 nginx 没隔离好还会影响其他业务
  当然如果 nginx 是前端的一部分打包到 docker 里了当我没说 在哪做都一样 自己高兴就好
  不过看主这描述 估计是前端扔过来的需求 所以 参见第一点

• 資深大佬 : GopherTT

  SEO router mode: ‘history’ Nginx 301

• 資深大佬 : Amit

  Nginx 就是个中间件，尽量少一些业务的配置（特别是这种针对单个路径的，假如这个路径后面不需要了 Nginx 是不是还要去掉配置 reload ？更新后端服务风险肯定比更新前端大吧）。33 说的对，前端不需要跳转，指向同一个组件就行了。退一步说，即使是后端做，我宁愿在 web 应用中做 redrict 也不想 Nginx 来实现，减少运维方面的配置也算是变相的提高服务稳定性了，因为你不知道部署的时候运维有没有把这个配置漏掉或交接给其他人的时候有没有在文档中把这条规则加上。