必须在install阶段用cache.addAll()预缓存CSS，否则离线时因渲染阻塞导致白屏或样式断裂；路径须与HTML中href完全一致，且需在fetch事件中按destination==='style'拦截并respondWith，配合CACHE_NAME版本更新与activate阶段清理旧缓存。
必须在 install 阶段用 cache.addAll() 预缓存 CSS
不是“可以”，是“必须”。CSS 是渲染阻塞资源，HTML 解析到 <link rel="stylesheet" href="styles.css"> 时会同步等待响应。若此时断网，且 Service Worker 还没把 styles.css 存进缓存，请求直接失败，页面白屏或样式断裂——这不是缓存逻辑写错了，是根本没让它提前就位。
常见错误现象：cache.addAll(['styles.css']) 写了但 DevTools → Application → Cache Storage 里找不到该文件；控制台无报错，静默失败。
- 路径必须与 HTML 中
href的值完全一致：比如 HTML 是/css/main.css，就不能写成css/main.css或./css/main.css - 构建后路径可能被重命名（如 Webpack/Vite 输出
main.a1b2c3.css），缓存列表里必须填最终产物名，不是源文件名 - 带查询参数的 URL（如
styles.css?v=2.1）会被当作独立缓存键，后续请求必须含相同参数才能命中；不推荐，改CACHE_NAME更可靠
fetch 事件中必须拦截并返回 CSS 缓存
install 阶段缓存只是“存进去”，不等于“能用上”。Service Worker 还得在运行时把对 CSS 的请求真正导向缓存，否则即使缓存存在，浏览器仍会尝试发网络请求并失败。
关键点：不能只靠 caches.match(event.request) 泛匹配，要加类型过滤，避免误伤其他请求。
立即学习“前端免费学习笔记（深入）”；
- 建议判断
event.request.destination === 'style'再走缓存逻辑 - 必须调用
event.respondWith()，否则请求不被拦截，仍走网络 - 兜底逻辑要保留：若缓存未命中，仍需
fetch(event.request)回退，否则开发阶段热更新会失效
CSS 缓存失效必须靠 CACHE_NAME 更新驱动
修改一行 CSS 后用户看不到效果？大概率是 CACHE_NAME 没变。Service Worker 缓存不会自动更新，旧缓存永不淘汰，除非你主动换名字。
典型错误：业务代码里改了版本号，但 sw.js 文件内容一字未变，浏览器判定“无新 SW”，根本不触发 install。
-
sw.js必须随版本变更（哪怕只改一行注释），浏览器才认为有新版本 - 每次发版后务必检查：
caches.open('shell-v2').keys()是否真包含目标 CSS 路径 - 激活阶段要清理旧缓存：在
activate事件里caches.delete()掉非当前CACHE_NAME的缓存，避免磁盘堆积
离线加载失败？先确认协议和环境是否合法
90% 的“CSS 缓存无效”问题，其实卡在启动方式上——file:// 协议下 Service Worker 完全不工作，这是浏览器强制限制，任何代码都绕不过。
开发阶段必须用本地服务器（如 npx serve、python3 -m http.server 或 Vite/HBuilder 内置服务）启动，且确保地址是 http://localhost:xxxx 或 https:// 开头。
- 检查 DevTools → Application → Service Workers 面板，确认状态为 “activated and is running”
- 查看 Network 面板，CSS 请求的 “Size” 列是否显示
from ServiceWorker，而不是from disk cache或空白 -
index.html本身也必须被cache.addAll()缓存，否则连 HTML 都打不开，CSS 根本没机会被请求
