base标签不参与浏览器缓存控制，仅在html解析阶段重写相对url解析起点；缓存行为完全由服务器响应头（如cache-control）决定，与base无关。
base 标签不参与浏览器缓存控制
<base> 标签和 Cache-Control、Expires 等缓存机制完全无关。它只在 HTML 解析阶段重写相对 URL 的解析起点，不影响任何 HTTP 缓存头的生成或行为。你在 里加了 <base href="/app/">，并不会让浏览器多缓存一秒，也不会让资源跳过协商验证。
常见误解是：「配了 <base>，资源路径统一了，缓存就更可控」——错。路径变了，但缓存策略仍由服务器返回的响应头决定。哪怕所有 src 都被 <base> 拼成 https://cdn.example.com/v3/js/app.js，如果服务器对这个 URL 返回了 Cache-Control: no-cache，它照样不进强缓存。
base 标签间接影响缓存命中率
真正起作用的是路径一致性。如果 <base href="/myapp/"> 和构建产物（如 Webpack 的 publicPath）、CDN 路径、Service Worker 预缓存列表中的前缀不一致，就会导致：
- HTML 中写的
<script src="main.js"></script>被解析为/myapp/main.js，但 Service Worker 里预缓存的是/assets/main.js→ 缓存未命中，发起网络请求 - Vite 构建时设了
build.base = "/subpath/"，但 HTML 没配<base>→ 浏览器按当前页面 URL 拼出http://localhost:3000/subpath/main.js，而 SW 缓存的是self.location.origin + "/subpath/main.js"→ 表面一致，实则 origin 可能是https://prod.example.com，线上 404 - 本地开发用
file://协议打开 HTML，<base href="/app/">生效，但所有资源请求都变成file:///app/logo.png→ 直接失败，且 Network 面板看不到请求（被浏览器拦截）
为什么你查不到 base 和缓存的官方关联文档
因为 W3C 和 WHATWG 规范里，<base> 属于「HTML 解析模型」范畴，而缓存属于「HTTP 协议层」行为。两者在浏览器中处于不同处理阶段：
-
<base>在 HTML parser 初始化时读取，仅影响后续标签属性中「纯相对路径」（如logo.png、style.css）的解析逻辑 - 缓存决策发生在 fetch 请求发出后，由网络栈根据响应头（
Cache-Control、ETag等）执行，与 HTML 解析无关 -
fetch('./api')、import('./utils.js')这类运行时路径完全不受<base>影响，它们走的是 JavaScript 模块解析规则
所以你在 MDN 或 HTML Living Standard 里搜 base cache，结果为空——不是文档漏了，是这事本来就不归它管。
实际部署中最容易漏掉的一环
SPA 部署时，<base href="/subpath/"> 必须和三处严格对齐：
- 构建工具输出的资源路径（Vite 的
build.base、Webpack 的output.publicPath） - 后端路由 fallback 配置（Nginx 的
try_files $uri $uri/ /subpath/index.html） - Service Worker 中
precacheAndRoute列表里的 URL 前缀（不能写死/subpath/，得用self.location.origin + '/subpath/'动态拼）
漏掉任意一个，资源可能加载成功但缓存失效，或者加载失败还查不出原因——因为浏览器既不报错，也不警告，只是默默按原始页面 URL 去发请求。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
