客户端window.location.href与Express res.redirect重定向方案对比

两种方案没有绝对的“更优”，二者存在非常明确的行为差异，适用场景完全不重叠，你看到两种实现都被广泛使用是非常正常的。

核心差异 #

• 执行逻辑完全不同：
  服务端跳转（方案2）是Express通过res.redirect()返回301/302类的标准HTTP重定向响应，浏览器收到响应后会自动完成地址跳转，整个过程不需要前端写任何JS介入处理；
  客户端跳转（方案1）里的/redirect接口本质只是个“查询目标地址”的普通数据接口，服务端只把目标URL当普通字符串返回，真正的跳转动作是前端拿到返回值后，手动给window.location.href赋值触发的。
• 链路开销不同：
  服务端跳转走浏览器原生重定向逻辑，没有额外的逻辑等待成本；客户端跳转多了一段前端JS执行的环节，如果前端在跳转前要加别的逻辑，会拉长用户等待跳转的时间。
• 灵活度不同：
  服务端跳转的行为完全遵循HTTP标准，前端没法在跳转过程中插入自定义逻辑，也很难捕获跳转过程中的异常做兜底；客户端跳转的控制权完全在前端，你可以在拿到URL之后做任意操作——比如先弹个“操作成功”的提示、上报个跳转埋点、把前端侧生成的临时参数拼到URL后面、校验URL合法性不通过就跳错误页，这些都是服务端跳转做不到的。
• 适配场景不同：
  如果触发跳转的是浏览器原生行为，比如用户直接在地址栏输地址、点普通<a>标签、提交原生表单，这类请求根本不会经过前端JS处理，只能用服务端跳转，客户端方案完全不生效。
• SEO效果不同：
  服务端返回的301/302状态码可以被搜索引擎识别，会正确传递页面权重；客户端JS触发的跳转搜索引擎爬虫通常不会执行，对SEO不友好。

选型参考 #

官方文档默认放服务端跳转的示例，是因为这是Express框架原生支持的、最符合HTTP规范的通用实现，不需要前后端额外配合，覆盖了80%以上的常规跳转需求。

• 直接选服务端跳转的场景：
  • 跳转由浏览器原生行为触发，没有JS介入空间
  • 跳转前不需要前端做任何额外操作
  • 面向公开内容页，需要考虑SEO效果
  • 追求最短跳转路径，不想加多余的前后端联调成本
• 选客户端跳转的场景：
  • 跳转是在异步请求（AJAX/Fetch）的回调里触发，比如用户提交表单后需要先提示成功再跳转
  • 跳转前需要前端执行自定义逻辑：埋点上报、本地缓存清理、用户二次确认、拼接前端侧独有的参数
  • 需要自定义跳转异常的兜底逻辑，避免跳转失败直接出浏览器报错页
  • 有特殊的跨域跳转适配需求，需要手动调整跳转时的请求头、上下文参数

内容的提问来源于stack exchange，提问作者Esqarrouth