看似普通，其实有门道｜一起草——跳转逻辑这件事 | 结果下一秒就反转？这条冷知识救过我
跳转，看起来只是“从 A 到 B”，但在网页、App、表单、追踪与用户体验之间，它决定了很多细节会不会翻车。那次我差点把一个活动的全部转化给作废了，幸好一条冷知识救了我——现在把那些容易被忽略的门道都整理出来，给你一份能马上用的跳转清单。
先讲个短故事 一次促销，落地页接收了大量来自广告的 UTM 链接，结果报名表单提交后跳到感谢页，转化统计却异常低。前端是用 client-side 重定向把用户送到第三方支付页，后来才发现第三方把 referrer 和 UTM 丢掉了，统计和归因全乱套。最终解决方法是：把参数在服务端保留并在跳转链上带上，或者先把关键参数存入 session/localStorage，再用 replaceState 去跳。那一刻我才真切体会到：跳转不是“简单的导航”，它在悄悄带走信息或改变浏览器行为。
跳转的几条容易被忽视的门道（实操版）
- 302/301/307/303 有差别：
- 301（永久重定向）适合 SEO 长期迁移；302（临时）会被浏览器/爬虫当成短期；303 用于让 POST 变 GET（常在表单提交后跳到结果页）；307 保留原始请求方法（POST 会继续是 POST）。当你需要保留 POST 数据或方法，优先考虑 307/308 而不是传统 302。
- 表单提交后的重复提交：用 PRG（Post/Redirect/Get）模式避免用户刷新重复提交。后端返回一个 303/307 指向结果页，再用 GET 拉取结果。
- 前端跳转 vs 服务端跳转：前端（window.location.href / single-page 的路由）会暴露中间状态且依赖浏览器 JS，服务端跳转（HTTP 重定向）则更可靠用于保留 headers/referrer。按场景选择：需要保留来源和 SEO 时优先服务端；需要平滑体验和状态管理时用前端。
- 保留 UTM/来源信息：第三方页面、跨域跳转或中间页面常会丢掉 UTM。解决办法：把关键参数在服务器端写入 session 或在 localStorage 保存，并在后续链路里附加；或者把参数放在 fragment（#后面）并由客户端读取再附加。
- 控制历史记录：window.location.replace(url) 不会在历史栈新增记录，适合登录/支付后避免用户点击回退看到中间页；history.pushState 则会新增一条。根据是否允许回退来选用。
- OAuth、扫码、深链的陷阱：授权跳转常常被浏览器或第三方拦截，导致 state 参数丢失或用户回流到错误页面。解决办法是用短期可校验的 state 存储在后端，并在回调时校验；若要支持多平台，先把目标信息写入后端并生成一个短 ID，通过该 ID 进行跳转。
- 单页应用（SPA）导航守卫：路由拦截器执行顺序会影响登录重定向逻辑。避免在守卫里做异步过多的重定向决策，先把用户状态和要跳转的目标参数确定，再做一次明确的 replace/push。
那条救命的冷知识（直接给你用） 浏览器在处理重定向时对请求方法的“默认行为”并不统一：历史上的 302 在有些浏览器会把 POST 改成 GET，导致表单提交数据丢失；307/308 明确要求“保留方法和请求体”。当你需要保证 POST 不被改掉、或后端要继续处理原始请求数据的时候，使用 307（临时）或 308（永久）比 302/301 更可靠。
一个最常见的场景示例（结论可复用） 场景：用户从广告到落地页（含 UTM），填写表单提交后要跳到第三方支付页，但支付页不保留 UTM，且需要避免用户回退看到提交页。 推荐流程： 1) 表单提交到你后端（POST）。 2) 后端记录参数和订单，返回 307 重定向到你的“跳转中转页”携带一个短 ID（例如 /goto/{shortId}）。shortId 在服务器能查到所有来源信息。 3) 中转页用 replaceState 跳向第三方支付（或直接由后端 302/307 跳），并在必要时把 shortId 作为参数带上或在服务器端完成把 UTM 写入第三方回调里的必要字段。 4) 支付回调使用 shortId 恢复来源和用户信息，统计不丢失。
精简的检查清单（发布/上线前照着看）
- 这次跳转是临时还是永久？SEO 要用哪个状态码？
- 是否要保留 POST 数据或原请求方法？考虑 307/308。
- UTM/referrer 会丢吗？要不要把参数存在服务端或 localStorage？
- 是否要避免用户回退看到中间页？用 replace。
- OAuth/深链有无 state 校验和短 ID 方案？
- SPA 的路由守卫是否会重复触发跳转？异步逻辑是否收敛到一次决策？
结语 跳转不是简单换地址，那一秒反转可能来自浏览器对方法的重写、第三方对 referer 的处理、或者你忽略的历史记录逻辑。掌握几条冷知识，少走很多弯路。想把你当前的跳转流程把关一遍？把场景、现有实现和痛点发来，我们一起草，顺手把逻辑打磨得顺又稳。
