表单跳转由 action 和 target 共同控制：action 指定提交地址（绝对或相对路径），target 决定响应展示位置（如 _blank 或 iframe）；验证失败时 preventdefault()，成功则交由浏览器自然跳转；服务端返回 303 最可靠。
form 的 action 和 target 属性决定跳转行为
表单提交后的跳转，本质由 action 和 target 两个 HTML 属性共同控制，不是靠 JS “额外跳转”。action 指定发往哪，target 决定响应在哪展示。
常见误区是写 <button target="_blank"></button> 或在 JS 里反复设 window.location.href，结果表单仍刷新当前页——因为浏览器只认 <form></form> 标签上的 target，且必须和 action 配合生效。
-
action="/login"：绝对路径，提交到根目录下的/login（无论当前页面在哪） -
action="success.html"：相对路径，基于当前 URL 目录解析（如当前页是/admin/edit.html，则提交到/admin/success.html） -
target="_blank"必须写在<form></form>上，否则无效；新开页显示响应，原页面不动 -
target="myframe"需搭配<iframe name="myframe"></iframe>，可隐藏（style="display:none"），但不能用hidden属性
用 JavaScript 拦截时，别无条件 preventDefault()
如果加了 event.preventDefault() 却没做后续处理，表单就彻底不提交了——哪怕验证通过、action 也写对了，页面也不会跳转。
正确做法是：只在验证失败时阻止默认行为，验证成功则放行，让浏览器按 action + method 自然跳转。
- 调用
form.checkValidity()触发原生 required/type 验证，失败时再e.preventDefault() - 不要在 submit 事件里直接写
window.location.href = "xxx"，这会绕过表单数据提交 - 若需异步提交（如 fetch），跳转必须放在
response.ok分支内，且确保服务端返回 200 - 用
fetch提交后跳转，记得用new FormData(form)而非form.serialize()（后者非原生 API）
服务端返回 303 是最语义化、防重复提交的方案
前端控制跳转容易漏掉数据一致性校验，比如用户点了两次提交按钮。服务端返回 303 See Other 状态码，强制浏览器用 GET 请求跳转到新页面，天然避免刷新重复提交。
它比前端 window.location.href 更可靠，也比 302 更符合 POST 后重定向的 HTTP 语义。
- PHP：用
header("Location: /dashboard"); http_response_code(303); exit(); - Express：用
res.redirect(303, "/dashboard") - Flask：用
return redirect("/dashboard", code=303) - 注意：303 响应体应为空或极简，浏览器不会渲染它，只执行跳转
target="_blank" 被拦截？试试 iframe 替代方案
Chrome/Safari 对非用户手势触发的 target="_blank" 会静默拦截，尤其在 Promise 回调、定时器或自动 submit() 场景下。控制台出现 Failed to open window 就是这个原因。
用隐藏 <iframe></iframe> 是稳定替代：表单提交结果载入其中，再监听 load 事件做后续动作（如提取响应内容或触发跳转）。
-
<form target="resultFrame"></form>中的resultFrame必须与<iframe name="resultFrame"></iframe>的name完全一致 -
<iframe></iframe>用style="display:none"，不能用hidden属性（部分浏览器不触发load） - 监听
iframe.onload后，可通过iframe.contentDocument.body.innerHTML读取响应（仅同源） - 服务端返回纯 HTML 即可，无需改前端提交逻辑
action 就形同虚设。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
