这是一个创建于 2094 天前的主题，其中的信息可能已经有所发展或是发生改变。
前端要求用户访问 http://abc.com/xxoo#happy 跳转到 http://abc.com/xxoo/xxoo/#happy
我说在 js 里判断就行，
现在前端非要我在 nginx 上 302
 | 1 drydiy 2020-01-20 14:56:07 +08:00 这前端直接处理就可以了。 |
 | 3 GDC 2020-01-20 14:57:21 +08:00  1 个人习惯在后端（服务端）做，因为在前端做 需要加载页面后才执行，用户体验不好。 另外从 SEO 角度来说也应该服务端做（如果原地址不使用了） |
 | 4 madewocao 2020-01-20 14:57:28 +08:00 via Android 看你们关系好不好，工作量大不大 |
 | 5 BrbiwsFtd9zDGZqB 2020-01-20 14:58:37 +08:00 看谁嗓门大 |
 | 6 retanoj 2020-01-20 14:58:49 +08:00 这种打一架就行 |
 | 7 mxT52CRuqR6o5 2020-01-20 14:59:39 +08:00 via Android 如果是 js 用 history api 做跳转，性能和 nginx302 应该差不多 |
 | 8 pmispig OP @GDC 如果考虑到体验就不应该做这个跳转，因为这个跳转是 vue 同一个页面，指向同一个 index.html 和同一个视图,好像是为了解决 ie 的一个刷新页面丢失 #后面的参数的问题... 我也不知道这种骚操作哪里来的 |
 | 9 DelayNoMore 2020-01-20 15:23:04 +08:00 前端 redirect 不就可以了吗？ |
 | 10 keepeye 2020-01-20 15:24:41 +08:00 单页的话前端做 |
 | 11 q8164305 2020-01-20 15:27:03 +08:00 via Android 单页前端做，很简单，就一个 redict 配置就行了啊 |
 | 12 J735KILnHi7q49cv 2020-01-20 15:37:46 +08:00 结合楼上 SPA：前端合理， MPA：前端做会在前端多增加一次网络请求，用户体验不好 |
| 13 GDC 2020-01-20 16:00:35 +08:00 1 @pmispig 对噢，如果你要考虑 # 后面的部分，那只能前端做，因为 # 后的参数是不会发送到服务端的，服务端也没法准确跳转（只能跳到新地址的首页去了） |
 | 15 heiheidewo 2020-01-20 16:41:01 +08:00 不管从哪方面讲都是后台做好啊：用户体验 和 SEO。 除非你想偷懒 |
| 16 pmispig OP @heiheidewo 从部署的角度来讲，我希望程序是完全自己独立的，按照一般标准就能跑起来，最讨厌要配这个配那个 |
 | 17 geekdocs 2020-01-20 17:02:30 +08:00 后端直接跳，不解释。 |
 | 18 Xusually 2020-01-20 17:07:12 +08:00 emmm....带了 hashtag，nginx 拿不到 啊，怎么跳 |
 | 19 zzzmh 2020-01-20 17:07:47 +08:00 如果是整站 SPA，就前端了，我是后端也学了 vue cli，这个用 vue-router 跳一跳美滋滋，还不刷新页面，不占用服务器算力 |
 | 20 hronro 2020-01-20 17:08:43 +08:00 你们 nginx 的配置难道不是前端在写吗？ |
| 21 geekdocs 2020-01-20 17:09:14 +08:00 nginx rewrite 模块 |
| 22 geekdocs 2020-01-20 17:10:38 +08:00 如果是分离且用了前端路由，可以让前端跳。 |
 | 23 wee911 2020-01-20 17:11:04 +08:00 看具体情况，http://abc.com/xxoo#happy 这个错误链接说导致的谁处理， 前端自己不可能产生一个不存在的路由，大概率历史原因或者后端造成的。 |
 | 24 chairuosen 2020-01-20 17:11:56 +08:00 如果前端部署在根目录,并且是业务跳转比如 /跳 /login，前端做。 如果前端部署在二级子目录或者非业务跳转，比如活动短网址，ngxin 做。 |
 | 25 jkmf 2020-01-20 17:14:01 +08:00 后端咋判断？#后的内容后端是拿不到的 |
 | 26 shintendo 2020-01-20 17:14:27 +08:00 为什么都说是 spa 内跳转……这不改的是 hash 前面的路径吗 |
 | 27 zhgg0 2020-01-20 17:14:55 +08:00 如果是因为历史遗留，就这一种情况，我个人觉得配 ngnix 302 比较合理。 |
 | 28 sm0king 2020-01-20 17:17:10 +08:00 那个~~ 不担心白屏怎么做都可以。 |
 | 29 DL9412 2020-01-20 17:17:49 +08:00 这个又有 path 又有 hash 的，总不能是用户自己输的吧，直接去把跳过来的地方改掉不就好了 |
 | 30 Idealyouth 2020-01-20 17:19:24 +08:00 nginx 上做啊 |
| 31 Idealyouth 2020-01-20 17:19:45 +08:00 @q8164305 是很简单，但是没必要 |
 | 33 Sapp 2020-01-20 18:01:17 +08:00 为什么要跳转？ 直接通过路由指向同一个组件不就行了么？ |
 | 34 Zach369 2020-01-20 18:13:09 +08:00 我现在的态度是: 能自己做的就自己做....懒得吵 |
 | 35 imswing 2020-01-20 18:45:08 +08:00 via iPhone 你们说的前端 redirect 是啥。。。。 |
 | 36 maple3142 2020-01-20 19:50:42 +08:00 via Android https://stackoverflow.com/a/5915350/6885801 在新的器上面的 302 redirect 是自保留 hash 的 |
 | 37 Torpedo 2020-01-20 19:53:44 +08:00 应该服务端做。楼上说 hash 的，这个场景根本不影响。 现在是把一个 url 映射到另一个，必然是服务端做。 要是前端做了，那会先访问一个 html，然后执行 js，才会跳转。 服务端做，第一时间就能跳过去 |
 | 38 rioshikelong121 2020-01-20 20:21:38 +08:00 我感觉不应该在前端做。这种规则尽量不要写在代码里面，不然变更的话还得重新发布，放在 nginx 上配置我感觉更灵活一点。 |
 | 39 KuroNekoFan 2020-01-21 07:14:22 +08:00 via iPhone 前端做就前端做吧，不碍事 |
| 40 KuroNekoFan 2020-01-21 07:20:05 +08:00 via iPhone 之前看过一条微博，说新浪微博的某个跳转之前是 302redirect，后来改成页面 location.href 了 或许可以这么说：由前端来实现是更实用主义的做法 |
 | 41 buffgek 2020-01-21 10:22:57 +08:00 听产品经理的. 他让谁改 谁就改. |
 | 42 elekids 2020-01-21 11:58:03 +08:00 Nginx 做跳转，不解释 |
 | 43 xderam 2020-01-21 13:32:35 +08:00 via iPhone 看需求 常用的跟业务无关的可以酌情做几个 不然后患无情 业务变更走不了代码 ci cd 流程 变成了运维变更 时间和风险系数都会变大 nginx 没隔离好还会影响其他业务 当然如果 nginx 是前端的一部分打包到 docker 里了当我没说 在哪做都一样 自己高兴就好 不过看楼主这描述 估计是前端扔过来的需求 所以 参见第一点 |
 | 44 GopherTT 2020-01-21 14:40:33 +08:00 SEO router mode: 'history' Nginx 301 |
 | 45 Amit 2020-01-21 15:17:14 +08:00 Nginx 就是个中间件，尽量少一些业务的配置（特别是这种针对单个路径的，假如这个路径后面不需要了 Nginx 是不是还要去掉配置 reload ？更新后端服务风险肯定比更新前端大吧）。33 楼说的对，前端不需要跳转，指向同一个组件就行了。退一步说，即使是后端做，我宁愿在 web 应用中做 redrict 也不想 Nginx 来实现，减少运维方面的配置也算是变相的提高服务稳定性了，因为你不知道部署的时候运维有没有把这个配置漏掉或交接给其他人的时候有没有在文档中把这条规则加上。 |
Select Language