是，但仅影响未显式设置target的和<form>元素；显式声明target的链接不受影响，且base不自动添加rel="noopener noreferrer"，存在安全风险。
base target="_blank" 会把所有链接都新窗口打开吗
会，但只影响那些没显式写 target 的 <a> 和 <form> 元素。一旦某个 <a href="..."> 自己写了 target="_self"，<base> 就完全不起作用。
常见误判是：加了 <base target="_blank"> 后，发现锚点链接（href="#section"）、空链接（href="#"）、javascript:void(0) 也跳新页——这不是 bug，是规范行为：只要没显式声明 target，就走 <base> 的默认值。
-
<base>必须放在<head>最前面，且整个页面只能有一个 - 它也会影响
<form>提交，比如登录表单提交后跳新标签页，用户可能以为操作失败 -
<iframe>的name属性若与target值匹配，也会被<base>干扰
base target="_blank" 不自动加 rel="noopener noreferrer" 是真问题
浏览器不会因为用了 <base target="_blank"> 就给每个链接补上 rel="noopener noreferrer"。这意味着所有被它影响的链接，都存在 window.opener 安全风险：新开页能调用 opener.location.replace() 劫持原页，或读取历史、触发卡顿。
你不能指望 <base> 帮你解决安全问题，它只管跳转位置，不管上下文隔离。
立即学习“前端免费学习笔记（深入）”；
- 必须手动给每个实际生效的链接补
rel="noopener noreferrer"，<base>不代劳 - 如果页面有动态生成的链接（比如 JS 拼的
<a>），它们不受<base>影响，但也容易漏掉rel - 旧版 Safari 对
rel="noopener"支持不全，单独写rel="noreferrer"无效，必须配对
为什么多数项目不该用 base target 控制新窗
表面省事，实则边界模糊、副作用难控。真正难处理的不是怎么设，而是“谁会被影响、谁会被漏掉、谁因此变慢”。
-
<base>在 Shadow DOM 或 Web Components 中作用范围受限，常失效 - SSR 渲染时无法按设备/上下文（如是否在 iframe 内）动态切换，不如服务端判断后直出属性
- 测试成本高：要专门检查锚点、空链接、表单、JS 链接是否被意外带上新窗口行为
- 更可控的做法是用 CSS 类（如
class="external"）+ JS 批量加target和rel，或模板引擎预渲染
如果非要用 base target，至少做三件事
别只写 <base target="_blank"> 就完事。最小安全闭环必须包含：
- 确认
<base>在<head>第一行，且无重复 - 人工或脚本扫描所有未显式设
target的<a>，确保它们确实需要新窗；内部导航链接建议显式写target="_self" - 对所有实际被
<base>影响的链接，补上rel="noopener noreferrer"—— 这步不能省，也没有替代方案
真正容易被忽略的是：哪怕你只改了一个 <base> 标签，也要重新验证表单提交、锚点滚动、iframe 加载、移动端 WebView 行为——这些地方不会报错，但会悄悄坏掉。
