base标签不能实现资源动态版本控制，它仅静态设定相对URL解析基准，不生成哈希、不替换路径、不校验存在性；真正版本控制需构建工具在生成阶段注入带版本标识的实际URL。
<base> 标签不能实现资源动态版本控制，它只影响相对 URL 的解析基准，不参与版本生成、哈希注入或运行时路径替换。
为什么<base href>不是版本控制方案
它只是让所有相对路径（如 js/app.js、css/main.css）以指定前缀为根来解析，比如设为 <base href="/v2.1/"> 后，js/app.js 就变成请求 /v2.1/js/app.js。但这个 v2.1 是硬编码的，无法自动随构建变化；也不会把 app.js 替换成带哈希的 app.a1b2c3.js；更不会校验该路径是否存在。
常见错误现象：
-
<base href="/v2.1/">加了之后，<img src="logo.png">请求的是/v2.1/logo.png，但实际文件在/v2.1/assets/logo.png→ 404 - API 调用
fetch("api/users")也被重写成/v2.1/api/users，后端没配对应路由 → 请求失败 - 构建升级到 v2.2 后忘了手动改
<base>，所有资源仍从 v2.1 加载 → 用户看不到新逻辑
真正起作用的版本控制发生在构建阶段
动态版本控制依赖构建工具在生成 HTML 时，把资源路径替换成带版本标识的实际地址。浏览器加载时看到的就是最终确定的 URL，无需运行时计算。
立即学习“前端免费学习笔记（深入）”；
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
关键操作点：
- Webpack：配置
output.publicPath+HtmlWebpackPlugin自动重写<script>和<link>中的路径 - Vite：设置
build.base = "/v2.1/"，它会重写所有静态导入和public/引用 - 手写 HTML：读取构建产物中的
manifest.json，用模板引擎（如 EJS、Nunjucks）动态插入带哈希的 URL - 禁止在 HTML 中写
src="./js/app.js"或href="css/style.css"—— 这类路径无法被构建工具识别并替换
服务端 fallback + 客户端校验才是安全跳转的关键
如果真要支持类似 /v2.1/index.html → /v2.2/index.html 的自动升级，靠 HTML 标签做不到，必须由 JS 主动判断并跳转。
正确做法是：
- 从
location.pathname提取当前版本段（如匹配/^\/(v\d+\.\d+)/） - 用
fetch("/v2.2/index.html", { method: "HEAD" })预检目标页面是否可访问 - 仅当返回 200 时才执行
window.location.href = "/v2.2/index.html" - 跳转前清除可能污染的旧缓存：
localStorage.removeItem("app-state")等 - 避免使用
<meta http-equiv="refresh">，它不支持条件判断且造成白屏
最易被忽略的一点：CSS 中的 url() 函数也受 <base> 影响，但开发者常以为只有 HTML 标签里的 src 和 href 才受影响。一个 background: url(images/bg.png) 在加了 <base href="/v2.1/"> 后，实际请求的是 /v2.1/images/bg.png —— 如果你的 CSS 文件本身在 /v2.1/css/ 下，而图片在同级 /v2.1/images/，那没问题；但如果图片放在 /public/images/ 且未同步调整路径，样式就直接失效。
