localstorage 缓存静态资源的关键在于结构设计、加载时机与版本控制三者协同：优先缓存体积适中、低频更新、首屏关键的 js/css/小图标；用构建哈希做版本标识防脏缓存；分阶段加载并附带元信息与容错清理机制。
LocalStorage 存静态资源，核心不是“能不能存”，而是“怎么存得稳、读得准、换得及时”。它不替代 HTTP 缓存，而是补弱网、防清缓、提首屏后二次加载速度的实用手段。关键在结构设计 + 加载时机 + 版本控制，三者缺一不可。
明确哪些资源适合放进 localStorage
优先缓存体积适中、变动频率低、对首屏影响大的资源：
- JS 文件：如 vendor.js、runtime.js、基础工具库（lodash、moment），不建议缓存整个 app.js（易过期）
- CSS 文件：全局样式表、主题 CSS，避免缓存带动态变量的内联样式
- 小图标/字体文件：Base64 编码后的 SVG 或 WOFF2（需控制单个不超过 200KB）
- 不推荐：图片（体积大、易超 5MB 上限）、HTML 模板（安全性风险高）、敏感配置（明文存储无加密）
用哈希值做版本标识，避免脏缓存
单纯按文件名存取会出问题——比如 app.js 更新了但 localStorage 还是旧版。必须绑定构建时生成的内容指纹：
- Webpack 构建输出带 hash 的文件名（如
vendor.abc123.js），同时生成一份manifest.json记录映射关系 - localStorage 中以
vendor-abc123为 key 存内容，而非vendor.js - 每次加载前先比对 manifest 中当前应加载的 hash 值，不匹配就跳过 localStorage，走网络请求并更新缓存
加载逻辑要覆盖真实场景
不能只等 window.onload 才存，否则用户已看到白屏才开始缓存。需分阶段介入：
-
首次加载时：用
fetch或XMLHttpRequest获取资源内容（注意设置cache: 'no-store'避免被中间缓存干扰），成功后写入 localStorage -
二次加载时：在资源 URL 解析阶段拦截（如通过动态
import()封装、或重写document.createElement('script')），优先读 localStorage，失败再 fallback 到网络 -
懒加载/异步资源：对
import('./module.js')类调用，提前预判依赖路径，检查对应 hash 是否已缓存，有则直接eval或注入 script 标签
加一层容错和清理机制
localStorage 不是保险箱，要应对容量满、数据损坏、跨域失效等情况：
- 写入前用
try...catch包裹，捕获QuotaExceededError，触发自动清理策略（如按时间戳删最早 20% 条） - 每个缓存项附带元信息：
{ content, ts: Date.now(), size: content.length, buildId: 'v2.3.1' }，方便诊断和灰度替换 - 上线新版本时，可主动清空旧 buildId 相关 key，或让服务端返回的 manifest 带强制刷新标记，前端识别后跳过读取
- 避免直接
localStorage.clear()，防止误伤用户其他数据（如登录态、偏好设置）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
