base target仅对未显式声明target的a和form生效，是兜底规则而非全局开关；显式设置target（含空值）即绕过base；动态修改需替换整个base元素并手动同步已渲染链接。
base target 属性只对未显式声明 target 的 a 和 form 生效
它不是“全局强制跳转开关”，而是兜底规则：只要某个 a 标签没写 target 属性（注意，target="" 也不算显式声明），它就会按 <base target="..."> 的值执行。但一旦写了 target="_self"、target="_blank"，哪怕值和 base 一样，也完全绕过 base 控制。
常见误判点：
-
href="javascript:void(0)"或href="#"不触发导航，target无效，base 更无从谈起 -
href是绝对 URL（如https://example.com）时，部分浏览器（尤其 Safari）会忽略base target，行为不一致 -
form元素若没设target，提交后真会走 base 默认值——这常导致 CMS 后台表单提交后意外新开标签页，打断操作流
修改 base target 的唯一合法方式是替换整个 <base> 元素
DOM 中不能直接改 document.querySelector('base').target = '_self' —— 浏览器不会重新解析已生效的 base 规则。你只能移除旧的、插入新的：
const oldBase = document.querySelector('base');
if (oldBase) oldBase.remove();
const newBase = document.createElement('base');
newBase.target = '_self';
document.head.insertBefore(newBase, document.head.firstChild);
但要注意：
立即学习“前端免费学习笔记（深入）”；
- 必须插在
<head>最前面，否则可能被后续其他<base>覆盖（浏览器只认第一个） - 如果原
<base>还带href，新元素必须一并设置，否则资源路径解析会退回到当前页面 URL - 动态插入后，**已渲染的链接不会自动更新 target**，需手动同步：
document.querySelectorAll('a:not([target])').forEach(a => a.target = '_self')
为什么直接删掉 <base target> 有时也不起作用
不是 base 没删干净，而是页面里存在更隐蔽的干扰源：
- 第三方脚本（如统计 SDK、客服浮窗）可能悄悄注入自己的
<base>，且插在<head>开头 - 某些 CMS 模板在服务端拼接 HTML 时硬编码了
<base target="_blank">，前端 JS 删除后，下次路由切换或组件重载又恢复 - Vue/React 等框架中，
<router-link>或<Link>完全不走 HTML 原生target逻辑，它们的跳转由 JS 控制，base 对其零影响 - iframe 嵌入场景下，父页面的
<base>不会影响子 iframe 内容，但子 iframe 自己的<base>若被沙箱（sandbox属性）限制，target="_top"可能被静默降级为_self
真正安全可控的替代方案
依赖 <base target> 修改跳转行为，本质是在对抗 HTML 的自然层叠逻辑。更稳的做法是放弃兜底，改用显式控制：
- 对外链统一加 class：
<a href="https://..." class="external">，再用脚本批量补全：document.querySelectorAll('a.external').forEach(a => { a.target = '_blank'; a.rel = 'noopener noreferrer'; }) - 内部链接全部显式写
target="_self"，哪怕冗余——这是可读性与协作成本的合理折中 - 表单提交一律用 JS 拦截 +
fetch，彻底脱离原生form action的 target 机制 - 若必须用 base（比如 SPA 部署在子路径），只设
href，永远不要设target；跳转策略交给组件或路由层处理
最易被忽略的一点：base 的 target 修改，从来不是“改一个属性就生效”的简单操作；它牵动的是整个文档的导航契约，而这个契约在现代前端生态里，早已被 JS 和框架层层覆盖。
