直接缓存静态资源内容而非路径才能避免网络请求：首次fetch后存文本至localstorage，后续通过blob或动态标签注入执行；需版本控制、过期机制及异常兜底，移动端收益显著，pc端受限于http缓存效率与存储安全风险。
直接用 localStorage 缓存静态资源（如 JS、CSS 文件）的路径本身，并不能减少网络请求——路径只是字符串，不等于资源内容。真正起作用的是：把资源内容（如 JS 代码、CSS 文本）下载后存进 localStorage，后续通过动态创建 script/style 标签并注入内容来执行或应用，从而跳过重复 fetch。
缓存资源内容，不是只存路径
单纯保存一个 URL 字符串（例如 "/js/app.js"）到 localStorage，下次仍要发起 HTTP 请求加载它。必须把实际响应体（即 JS 或 CSS 的文本内容）存下来，才能避免请求。
- 首次加载时，用 fetch 获取资源，拿到 text() 后存入 localStorage（键名建议含版本号或哈希）
- 后续加载前先查 localStorage，若命中且未过期，则用 URL.createObjectURL(new Blob([content], {type: 'text/javascript'})) 或直接 eval()（仅限可信 JS）、document.write()（慎用）等方式注入执行
- CSS 可创建 style 元素，将缓存的 CSS 文本设为 innerHTML 后插入 head
适合移动端 H5，PC 端需谨慎
该方案在弱网、低配安卓设备上效果明显，因为 localStorage 读取快于网络协商缓存（304）；但在 PC 端收益有限：
- 现代浏览器 HTTP 缓存（Cache-Control + ETag）已非常高效，304 响应极轻
- localStorage 存储大体积 JS/CSS 可能触发存储上限（通常 5MB），且 eval 执行存在安全与调试风险
- SEO 场景下，内联或动态注入的 CSS/JS 不被搜索引擎良好识别
必须配套版本控制和过期机制
否则更新资源后用户无法感知，导致功能异常。推荐做法：
- 服务端输出唯一 pageVersion（如构建时间戳或 hash），作为 localStorage 键的一部分
- 每次加载前比对当前 version 与缓存中的 version，不一致则清旧存新
- 或为每项缓存附加时间戳和过期阈值（如 24 小时），读取时自动校验
注意兼容性与异常兜底
localStorage 并非 100% 可用：
- 隐私模式下可能被禁用（抛出 QuotaExceededError 或 SecurityError）
- 需 try/catch 包裹 setItem/getItem，并降级到 fetch 请求
- 监听 storage 事件可辅助多标签页同步，但不影响单页加载逻辑
