Service Worker 离线缓存需与 Nginx 响应头协同：HTML 用 no-cache + ETag，哈希静态资源用 public, max-age=31536000, immutable，API 接口用 no-store。
要让 Service Worker 的离线缓存策略真正可靠，Nginx 的响应头配置必须与之协同——不能冲突，也不能留空子。关键在于：Service Worker 控制的是“是否拦截请求、如何读写 Cache Storage”，而 Nginx 决定的是“浏览器是否发请求、发什么类型的请求（完整请求 or 条件请求）”。两者配合不好，就可能出现白屏、旧资源不更新、或离线时 404。
避免 Nginx 干预 SW 的控制权
Service Worker 需要对资源有完全的调度自由，尤其是 HTML 入口文件和关键 JS。如果 Nginx 对 index.html 设置了强缓存（如 max-age=31536000），浏览器可能直接从磁盘缓存返回旧 HTML，根本不会触发 SW 的 fetch 事件，导致新版本 SW 永远不被加载。
- HTML 文件务必禁用强缓存：用
no-cache或no-store，推荐no-cache（允许条件请求，配合 ETag/Last-Modified） - 不要在 HTML location 中使用
expires 1y或add_header Cache-Control "public, immutable" - 确保 Nginx 返回的 HTML 响应中包含
ETag或Last-Modified头（默认开启，勿显式关闭）
静态资源需支持“内容哈希 + 不变性”语义
Service Worker 常通过文件名哈希（如 main.a1b2c3d4.js）实现版本隔离。这类资源一旦发布，内容永不变更，Nginx 应明确告知浏览器“无需验证”。
- 匹配带哈希的资源（正则如
\.[a-f0-9]{8,}\.(js|css|png|webp)$） - 设置
Cache-Control: public, max-age=31536000, immutable -
immutable是关键：它告诉浏览器“这个 URL 永远对应同一份内容”，跳过If-None-Match等验证请求，既节省带宽，又避免 SW 和浏览器缓存竞争
API 与动态接口：明确区分可缓存性
Service Worker 可能为某些 API 实现离线 fallback（如返回缓存数据 + 提示“已离线”），但 Nginx 不应擅自缓存这些响应，否则会掩盖真实状态或返回过期数据。
HISUI 前端框架基础开发指南。HISUI 是基于 easyui 二次开发的 jQuery UI 组件库，专为医疗信息系统设计。当涉及 HISUI 组件开发、jQuery easyui 表格/表单/布局/窗口、医疗系统前端页面编写时使用此 skill。 涵盖 40 个组件的官方文档参考，支持声明式与编程式两种初始化方式，提供 $cm/$m 数据访问方法。
立即学习“前端免费学习笔记（深入）”；
- 对
/api/、/v1/等路径，统一设为Cache-Control: no-store（彻底禁用所有缓存） - 若后端确需代理缓存（如只读查询），必须用
proxy_cache显式控制，并确保Cache-Control响应头由后端生成，Nginx 不覆盖 - 避免用
expires指令处理动态接口——它只适合静态资源，且易覆盖后端本意
验证与调试要点
配置生效后，需检查三类响应头是否符合预期：
-
HTML：应含
Cache-Control: no-cache、ETag（或Last-Modified），无immutable -
哈希静态资源：应含
Cache-Control: public, max-age=31536000, immutable，无no-cache -
API 接口：应含
Cache-Control: no-store，且X-Cache-Status（如启用 proxy_cache）不应为HIT（除非你明确设计了代理层缓存）
可通过浏览器 DevTools → Network → 查看单个请求的 Response Headers 快速确认；也可用 curl -I https://yoursite.com/app.js 辅助验证。
