标签通过修改 document.baseuri 影响 fetch、xmlhttprequest、worker 和 css url() 的相对路径解析，但不影响 es 模块 import；其值错误会导致插件资源批量 404 且无报错，唯一有效解法是配置插件使用绝对 url 或确保 与插件期望路径完全一致。
第三方插件的 fetch 和 import 不受 <base> 控制，但会意外继承 document.baseURI
很多第三方插件（比如图表库、富文本编辑器、埋点 SDK）内部用 fetch('./config.json') 或 import('./theme.js') 加载资源。你以为 <base href="/app/"> 只影响 HTML 里的 src，但它悄悄改了 document.baseURI——而浏览器对 fetch('./x') 这类相对路径的解析规则是：**以 document.baseURI 为基准**，不是以当前 JS 文件位置为准。
结果就是：fetch('./api/track') 实际发向 https://example.com/app/api/track，而非你预期的根路径或插件自身目录。后端没配这个前缀？404 就来了。
-
fetch()、XMLHttpRequest.open()、new Worker('./w.js')全部走这套逻辑 - CSS 中的
background: url(logo.png)同样被影响（HTML 解析阶段计算，非 CSS 引擎 resolve） - 但
import('./utils.js')是模块系统行为，仍以模块文件所在路径为基准，不受<base>影响
<base href> 写错导致插件资源批量 404，却没有任何控制台报错
这是最危险的情况：你写了 <base href="assets/"> 或 <base href="/admin">（结尾缺 /），浏览器直接静默丢弃整条标签。插件里所有硬编码的 <img src="icon.svg">、<script src="vendor.js"></script> 都退回到按当前页面 URL 解析——开发时可能碰巧能加载，上线部署到子路径后全挂。
常见无效写法包括：
-
href="static/"（缺协议或根斜杠） -
href="../lib/"（含..，规范禁止） -
href="/myapp"（结尾无/，Firefox 会把css/app.css拼成/myappcss/app.css） -
href="%PUBLIC_URL%/"（构建未替换，浏览器收到字面量字符串）
插件初始化前手动重置 document.baseURI 不可行
有人想用 JS 在插件加载前“修复”：document.head.innerHTML = '' 或删掉 <base>。没用。原因有二：
-
<base>的作用只在 HTML 解析阶段生效；DOM 创建后删掉它，已解析的<img src="x">不会重算，也不会影响后续fetch()的基准（因为document.baseURI已固化） -
document.baseURI是只读属性，无法通过 JS 赋值覆盖
真正有效的解法只有两个方向：要么让插件不依赖相对路径（配绝对 URL），要么让 <base> 的值与插件期望的路径完全一致——而这通常意味着你要去读插件文档，看它是否支持 basePath、cdnUrl 等配置项。
微前端或插件沙箱场景下，<base> 是全局污染源
在 qiankun、Garfish 等微前端框架中，子应用常被挂载到 /subapp/ 路径。若主应用写了 <base href="/subapp/">，所有子应用的 fetch('./api') 默认都带上这个前缀——但子应用自己的 API 很可能走独立域名或根路径。更糟的是，某些插件会缓存 document.baseURI 到闭包里，即使你切换子应用、动态卸载，它的请求基准也不会自动更新。
此时必须：
- 主应用禁用
<base>，改用构建工具（如 Vite 的build.base）控制静态资源路径 - 子应用自行通过
createWebHistory('/subapp/')或<router basename="/subapp"></router>管理路由，与资源路径解耦 - 插件调用处显式传入绝对 URL：
plugin.init({ apiBase: 'https://api.example.com/' })，绕过document.baseURI
记住：<base> 是个单向、不可逆、且极易被误用的 HTML 解析开关。它解决不了插件路径问题，反而会让问题更隐蔽——因为浏览器连 warning 都不给你。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
