禁用 <base> 标签更安全，因其易致路径重复、fetch/import/CSS不受控、锚点跳转异常、SSR/微前端冲突，且仅影响HTML解析的相对路径。
<base> 标签不是“设了就稳”，很多场景下它反而会引入不可见的路径错乱，尤其在现代前端工程中，禁用比滥用更安全。
SPA 部署在子路径但构建工具已配 base 或 publicPath
比如 Vite 项目已配置 build.base = '/admin/'，或 Webpack 的 output.publicPath = '/admin/'，构建后所有资源路径（js/app.js、css/index.css）都自动带上前缀。此时再手动在 HTML 中写 <base href="/admin/">，会导致资源 URL 被拼两次：/admin//admin/js/app.js —— 中间双斜杠触发 404。
- 构建工具生成的 HTML 通常已注入正确路径，
<base>属于冗余操作 - Vite 用户：删掉 HTML 中的
<base>，只保留vite.config.ts的base - Webpack 用户：确保
html-webpack-plugin不额外注入<base>，且模板中无手写标签
使用 fetch、import() 或 CSS @import 的项目
<base> 对这些完全无效，但开发者常误以为“统一设了 base 就万事大吉”。结果是：<img src="logo.png"> 加载正常，fetch('./api/user') 却发向 https://example.com/api/user（当前页路径），而非预期的 /admin/api/user。
-
fetch('./api/user')始终以当前页面 URL 为基准，不读document.baseURI -
import('./utils.js')解析依赖模块位置，与<base>无关 - CSS 中的
@import "reset.css"由 CSS 引擎解析，不受 HTML<base>控制
锚点跳转（a[href="#section"]）和 a[href="#"] 场景
一旦存在 <base href="https://example.com/sub/">，<a href="#top"> 会被浏览器解析为 https://example.com/sub/#top —— 这个 URL 不存在，触发整页重载（地址栏变灰、滚动回顶），而不是平滑锚点定位。
立即学习“前端免费学习笔记（深入）”；
-
href="#"在<base>下等价于跳转到 base URL，不是“当前页内” - SPA 中常用
href="#tab2"触发 JS 行为，但默认跳转会打断路由状态 - 修复方式不是调
<base>，而是改用href="javascript:void(0)"或event.preventDefault()
服务端渲染（SSR）或微前端子应用中动态插入 <base>
SSR 模板若在 <head> 中多次 render <base>（例如 header 组件和页面组件各输出一个），浏览器只取第一个，其余被忽略，且控制台提示 Multiple base elements detected. Only the first one is used.；更糟的是，若第一个 <base> 出现在 <title> 之后，它对前面已解析的 <link>、<script> 完全无效。
-
<base>必须是<head>中首个元数据标签，位置错等于没写 - 微前端场景下，主应用和子应用各自尝试设置
<base>，极易冲突 - 推荐方案：由主应用统一控制路径前缀，子应用完全不碰
<base>
最易被忽略的一点：<base> 的影响范围极窄——它只改 HTML 解析时的纯相对路径，而现代前端大量路径构造发生在 JS 运行时。与其花时间调试它是否生效，不如直接去掉，把路径逻辑收口到构建配置或代码中。
