<base>标签在file://离线环境下大概率失效，因浏览器对href校验严格：Chrome/Edge忽略无协议的/assets/，Firefox要求完整file:///绝对路径，含..一律被拒；它不干预Service Worker缓存、JS运行时路径或本地文件系统映射，仅静态解析HTML相对路径，且依赖HTTP协议才能可靠生效。
<base> 标签在离线网页浏览中**无法保障路径正确性**，它只影响 HTML 解析阶段的静态资源路径拼接，对离线环境下的文件系统协议（file://）、相对路径解析规则、缓存机制或 Service Worker 预缓存行为均无实质干预能力。
为什么 <base href="..."> 在 file:// 下大概率失效
浏览器对 file:// 协议下 <base> 的支持极不统一：
- Chrome 和 Edge 会严格校验
href值：若写成<base href="/assets/">，因缺少协议和主机名，整个标签被静默忽略；后续<img src="logo.png">仍按当前文件所在目录（如file:///D:/proj/index.html）拼接，变成file:///D:/proj/logo.png，而非你期望的file:///D:/proj/assets/logo.png - Firefox 要求
href必须是完整file://绝对路径，例如<base href="file:///D:/proj/assets/">；写成/assets/或./assets/全部无效 - 所有主流浏览器都拒绝解析含
..的href（如<base href="../static/">），离线调试时极易踩坑
<base> 不解决离线资源加载失败的核心问题
离线场景下资源 404 的主因不是“基准路径没设”，而是：
-
<base href="/app/">对file://页面完全无效——浏览器不会把/app/映射到本地某个文件夹 - CSS 中的
background: url(avatar.jpg)虽受<base>影响，但前提是 HTML 已成功加载并解析；而离线时若index.html本身路径不对（比如双击打开 vs 用本地服务器），连解析阶段都进不去 - Service Worker 的
cache.addAll()预缓存路径由脚本硬编码决定，与<base>无关；写错缓存路径（如漏掉/app/前缀）会导致离线时 fetch 失败，<base>压根不参与这个过程
真正能保障离线路径稳定的实操做法
与其依赖 <base>，不如直接控制路径生成源头：
立即学习“前端免费学习笔记（深入）”；
- 所有静态资源引用改用**根相对路径**（以
/开头），例如<script src="/js/app.js"></script>—— 这样即使没<base>，也能稳定指向站点根目录下的文件（前提是本地服务器能正确映射/到项目根） - 用本地开发服务器（如
npx serve、python -m http.server）代替双击打开file://文件；只有 HTTP(S) 协议下，<base href="/subpath/">才能被可靠识别 - 构建时通过模板引擎注入真实路径：比如 Hugo 用
<base href="{{ .Site.BaseURL }}">，Webpack 用html-webpack-plugin的templateParameters注入BASE_URL，避免手写死值 - 离线 PWA 场景下，Service Worker 缓存清单必须显式包含带前缀的完整路径（如
/myapp/js/app.js），且前端路由（Vue Router / React Router）的base配置必须与之严格一致；<base>只负责 HTML 层资源加载，其余环节它管不了
最常被忽略的一点：离线网页的“路径保障”本质是**部署结构 + 构建配置 + 运行时逻辑**三者对齐的问题。<base> 只是其中一环，且是最脆弱、最容易静默失效的一环。强行在 file:// 下用它，往往掩盖了真正的路径管理缺陷。
