表单提交后跳转应优先使用form的action属性配合后端302重定向，而非JavaScript跳转；后端处理完业务逻辑后返回302响应及Location头，确保可靠性、可回退性及容错性。
form 的 action 属性直接写目标 URL 就够了
表单提交后跳转，最简单的方式就是让 <form> 的 action 指向你要跳转的地址。浏览器原生行为会自动用 GET 或 POST 请求该地址，并加载返回的页面——这本身就是一次重定向（服务端未干预时）。
常见错误是以为必须用 JavaScript 手动 window.location.href，其实多数场景没必要。尤其当后端已处理完数据（如保存用户注册信息），直接返回 200 页面或 302 响应即可。
-
action值为相对路径（如"./success.html"）或绝对 URL（如"https://example.com/thanks"）都有效 - 若后端返回 HTTP 302/303 状态码 +
Locationheader，浏览器会自动跳转，此时action只需指向后端接口地址（如"./api/submit"） - 避免在
action里写javascript:void(0)或#后再用 JS 跳转——这绕过了表单默认语义，还可能破坏前进/后退逻辑
后端返回 302 重定向比前端跳转更可靠
用 JavaScript 在 submit 事件中调用 window.location.replace() 看似灵活，但有明显缺陷：如果表单验证失败、网络中断或 JS 报错，用户就卡在空白页或旧页面，且无法刷新重试。
真正健壮的做法是后端完成业务逻辑后，明确返回 HTTP 302 响应：
立即学习“前端免费学习笔记（深入）”；
HTTP/1.1 302 Found Location: /thank-you?status=ok
这样无论 JS 是否启用、是否出错，用户都能被正确跳转。同时支持浏览器历史回退（跳转前页面仍保留在 history 中）。
- Node.js（Express）示例：
res.redirect(302, "/thank-you") - PHP 示例：
header("Location: /thank-you", true, 302); exit; - Django 示例：
return redirect("/thank-you", status=302) - 注意不要混用 301（永久重定向）——表单提交是临时性动作，302 或 303 更语义准确
防止重复提交时别误杀重定向逻辑
加防重逻辑（比如禁用提交按钮）很容易干扰重定向流程。典型错误是在 submit 事件里直接 e.preventDefault()，又没手动触发跳转。
如果你必须用 JS 控制提交（例如要先校验、发 AJAX），请确保重定向发生在服务端响应成功之后，而不是表单提交瞬间：
- 用
fetch()提交后，在then()里调用window.location.href = "/success"或window.location.replace() - 禁用按钮后，务必在跳转前或跳转后恢复（否则用户刷新页面时按钮仍是禁用态）
- 如果后端返回的是 JSON（如
{ "redirect": "/success" }），那就按字段跳转，别硬编码 URL - 避免在
setTimeout里跳转——延迟不可控，可能被用户提前关闭页面
GET 表单重定向要注意 URL 长度和敏感参数
当 <form method="get"> 提交时，参数会拼到 URL 后（?name=xxx&email=yyy）。如果字段多或内容长，可能超浏览器 URL 长度限制（通常 2000 字符左右），导致截断或 414 错误。
更严重的是：这些参数会留在地址栏、历史记录、服务器日志甚至代理缓存中。密码、token、手机号等绝不能走 GET 重定向。
- 搜索类表单适合 GET + 重定向（利于分享、缓存）
- 登录、注册、支付等操作一律用
method="post"，后端处理完再 302 跳转到结果页 - 如果必须用 GET 传参，前端可先用 JS 清洗（如移除
password字段），再构造 URL 跳转 - Chrome 对地址栏显示的 URL 长度有视觉截断，但实际请求仍可能失败——得靠后端校验并降级处理
