base标签不适合做重构过渡，因其不支持渐进式切换、不兼容运行时路径重写、不参与构建流程协调；强行使用易致资源404、路由错位、静默失败且难定位。
<base> 标签不能作为“过渡方案”使用——它不支持渐进式切换、不兼容运行时路径重写、也不参与构建流程协调。强行在重构中依赖它，大概率导致资源 404、路由跳转错位、控制台静默失败，且问题难以定位。
为什么 base 标签不适合做重构过渡
重构的核心是路径解耦与分阶段验证，而 <base> 是一个解析期单点开关：一旦生效，所有后续纯相对路径（src="app.js"、href="style.css"）立刻按新基准拼接，没有“部分启用”或“条件 fallback”机制。
- 它不感知环境（开发/预览/生产），无法根据
process.env.NODE_ENV动态切换 - 它不参与打包逻辑，Webpack/Vite 的
publicPath或base配置若与之重复，会引发双拼路径（如/new//new/js/app.js） - 前端路由（Vue Router / React Router v6+）完全忽略
document.baseURI，必须手动配base或basename，否则router.push('/home')直接跳根域 - JS 中的
fetch('./api')、import('./utils')、CSS 中的@import全部绕过<base>，重构时需单独处理，无法统一收口
真正可行的过渡替代方案
重构中要控制路径变更影响范围，应放弃 <base>，改用构建层和运行时协同策略：
- Webpack/Vite 构建时用
base: '/new/'（Vite）或output.publicPath: '/new/'（Webpack），让所有静态资源引用自动带前缀，HTML 模板里不写<base> - 前端路由显式传入相同 base 值：
createRouter({ base: '/new/' })或<Router basename="/new/">，确保导航与匹配一致 - 服务端模板（如 Express/Nunjucks）在输出 HTML 前注入真实部署路径：
<base href="{{ deployBase }}">，但仅用于最终上线，不用于过渡阶段 - 本地开发用代理（如 Vite 的
server.proxy）或 mock 路由 fallback，避免直接依赖物理路径
如果必须保留 base 标签，这些坑必须避开
某些遗留系统已强依赖 <base>，重构时只能保留它，此时关键不是“怎么用”，而是“怎么不翻车”：
立即学习“前端免费学习笔记（深入）”；
-
href值必须是绝对 URL（如https://cdn.example.com/v2/）或合法根相对路径（/new/，结尾斜杠不可省），任何含../、assets/、%PUBLIC_URL%的写法都会被浏览器静默丢弃 -
<base>必须是<head>中第一个标签，放在<title>或<meta>后面会导致前面的<link>和<script>已按旧路径加载完毕 - 检查 DevTools Network 面板，确认
<img src="logo.png">发出的请求 URL 是否已正确拼接；不要只看 HTML 源码里的src属性值 - 禁用 JS 动态插入
<base>——document.head.appendChild(baseEl)对已解析的 DOM 完全无效，只会误导调试方向
最易被忽略的一点：即使 <base href="/new/"> 正确生效，它也只改 <img src="x"> 这类硬编码路径；所有 JS 运行时构造的 URL（包括 location.pathname、new URL()、fetch()）仍需你一行行检查并适配——这才是重构真正的体力活。
