base标签仅在HTML解析阶段重置纯相对URL的解析起点，必须为绝对URL或根相对路径（以/开头且结尾带/），否则静默失效；它不影响JS/CSS运行时路径、fetch、import等动态行为，与同源策略、CORS、跨域iframe限制完全无关。
base标签根本不影响跨域行为
<base> 标签和浏览器的同源策略、CORS、跨域 iframe 限制完全无关。它只在 HTML 解析阶段改写相对 URL 的拼接起点，不改变请求发起时的 origin、不绕过任何安全机制、也不影响 fetch 或 XMLHttpRequest 的跨域判定逻辑。
常见误解是：写了 <base href="https://api.example.com/"> 就能让 <img src="user-avatar.jpg"> 跨域加载资源——实际只会发出一个到 https://api.example.com/user-avatar.jpg 的请求，而该请求是否成功，取决于 api.example.com 是否允许当前页面 origin 的跨域读取（即响应头是否含 Access-Control-Allow-Origin），<base> 不参与这个判断。
-
<base href="https://third-party.com/">+<script src="app.js">→ 请求发向https://third-party.com/app.js，但若未配置 CORS，JS 加载失败且控制台报 CORS 错误，不是 404 -
<base href="//cdn.example.net/">+<link href="style.css">→ 协议跟随当前页，但 CSS 文件若禁止跨域读取（如未设crossorigin属性），样式仍可能加载失败或无法通过 JS 读取其规则 - 动态插入的
<iframe src="https://other-site.com/frame.html">不受<base>影响，它的跨域行为由 iframe 的 sandbox、allow、以及目标站点的 X-Frame-Options / Content-Security-Policy 决定
target="_blank" 和 rel="noopener" 才真正涉及跨域安全
当 <base target="_blank"> 生效时，所有未显式声明 target 的链接（包括跳转到不同域名的 <a href="https://evil.com">）都会在新标签页打开。但这会带来真实的跨域安全隐患：window.opener 在新页中默认可访问原页的 window 对象，恶意站点可通过 opener.location = "https://phishing.site" 劫持原页。
所以必须配合 rel="noopener"（或 rel="noreferrer"）来切断关联：
立即学习“前端免费学习笔记（深入）”；
- 仅写
<base target="_blank">→ 风险存在，尤其对用户可控的跳转链接（如评论区外链） - 正确写法应为
<base target="_blank" rel="noopener">，注意：HTML5 中rel属性在<base>上是合法的，且被 Chrome/Firefox/Edge 支持 - 若需兼容旧版 Safari（<a> 加
rel="noopener"更稳妥，因为部分旧引擎忽略<base>上的rel
base href 写跨域地址时的资源加载陷阱
用 <base href="https://cdn.example.com/"> 是常见做法，但它会让所有相对路径资源（如 <script src="main.js">）强制指向 CDN 域名——这本身没问题，但容易掩盖两个关键问题：
- CDN 返回的资源必须与当前页面同源（或显式支持 CORS），否则
fetch()、import()、new Worker()等运行时调用仍会因跨域被拦，<base>不提供任何豁免 - CSS 中的
url(./font.woff2)不受<base>影响，它始终相对于 CSS 文件自身位置解析；如果 CSS 托管在 CDN，但字体文件路径写错了（比如漏了fonts/子目录），就会 404，且和 base 无关 - 服务端渲染时若把
<base href="https://staging.example.com/">硬编码进 HTML，上线后忘记替换，所有静态资源将错误地从测试域名加载，导致生产环境大面积失败
真正需要跨域协同的场景：微前端与子应用通信
在微前端架构中，主应用常通过 <iframe> 或 customElements 加载子应用，此时 <base> 的作用范围严格限定在子应用自身的 HTML 文档内。子应用若部署在独立域名（如 https://widget.example.com/），它的 <base href="/sub/"> 只影响自己内部的 <img src="icon.png">，不会、也不能影响主应用的资源路径或通信方式。
子应用和主应用之间的跨域通信，依赖的是标准机制：
-
window.postMessage()+message事件监听，必须校验event.origin -
CustomEvent仅限同源 DOM 树，跨域 iframe 中无效 - 若子应用使用
import('./chunk.js')，其路径解析走 JS 运行时逻辑，不受主应用或自身<base>影响，但 chunk 必须部署在允许跨域读取的域名下（并配好crossorigin）
最容易被忽略的是：子应用的 <base href="/sub/"> 和主应用的路由前缀毫无关系；它们各自维护自己的路径逻辑，通信层才是唯一需要显式处理跨域的地方。
