确实控制表单提交目标，优先级低于表单自身 target 但高于无声明状态；未显式设 target 的表单会遵循 ，常见于新标签页意外弹出或被 csp/js 干预导致失效。
base target 属性确实会控制表单提交的目标窗口
<base target> 不是摆设，它对 <form></form> 的提交行为有真实约束力——只要该 <form></form> 没显式声明 target 属性，浏览器就会用 <base> 里指定的值作为默认目标。这个规则在所有现代浏览器中一致生效，包括 Chrome、Firefox、Safari（2026 年实测）。
常见误解是“<base> 只管链接”，其实它对 <form></form> 同样有效，且优先级低于表单自身的 target，但高于无声明状态。
-
<base target="_blank">会让所有没写target的表单提交到新标签页——这常导致后台管理页意外弹窗，打断操作流 -
<base target="_self">和不写target效果相同，但能明确覆盖上级模板（如 CMS 主题）里可能存在的<base target="_blank"> - 若表单已带
target="myframe"，则<base>完全不生效，哪怕myframe对应的<iframe name="myframe"></iframe>不存在
为什么表单提交后没跳转到预期窗口？
不是 <base> 失效，而是被更高优先级或运行时机制绕过了。最常踩的坑集中在三类：
-
<base>没放在内，或出现在多个位置（只认第一个，后面全忽略） - 表单用了
event.preventDefault()+ JS 提交（例如fetch()或axios.post()），此时target属性完全不参与导航 - 提交由非用户手势触发（如自动
form.submit()在页面加载后 100ms 执行），Chrome/Safari 会静默降级为_self，控制台可能不报错
验证是否真被 base 控制：临时删掉所有 JS，用原生提交测试；再检查 DevTools → Elements 面板里 <form></form> 元素上是否真的没有 target 属性（注意空字符串 target="" 仍走 base）。
target="_blank" 表单提交的安全与兼容性风险
直接写 <base target="_blank"> 很危险——它不会自动加 rel="noopener"，新标签页可通过 window.opener 访问并修改原页面 DOM，存在钓鱼和 XSS 风险。
- 服务端返回 JSON（如
{"ok":true}）时，浏览器会在新标签页直接渲染纯文本，不是跳转，也不是报错 - 跨域 iframe 内的表单若设了
target="_blank"，现代浏览器会因缺少rel="noopener"而拦截，表现为点击无反应 - 如果页面启用了 CSP（Content-Security-Policy），且未配置
popup-src，target="_blank"会被强制降级为_self
真正需要新开页时，应显式写 <form target="_blank" rel="noopener"></form>，而不是依赖 <base> —— 因为 <base> 不支持添加 rel。
更可控的替代方案：隐藏 iframe + formtarget
当 <base> 过于粗放、target="_blank" 又受限时，用隐藏 <iframe></iframe> 是目前最稳定的做法：
- 给
<form></form>设target="hidden-frame"，同时配一个<iframe name="hidden-frame" style="display:none"></iframe> - 服务端返回 HTML 响应（哪怕只是
OK），iframe 加载完成后触发load事件 - 监听
iframe.onload，读取iframe.contentDocument.body.textContent（同源前提下） - 多按钮不同目标？用
formtarget：
这个方案绕开了弹窗拦截、CSP 限制、opener 泄露，也避免了 <base> 对整个页面的副作用——它只作用于你明确写出的那几个表单。
真正难处理的是微前端场景（如 qiankun），其中沙箱会重写 window.open 和 location，此时 <base target> 和原生 target 都可能被拦截，必须改用 window.top.location.href = url 并确保由用户点击直接触发。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
