HTML文件不该长期缓存，否则用户卡在旧版本；应设no-cache,must-revalidate或max-age=0，而JS/CSS/图片等静态资源需用文件名哈希+immutable长期缓存。
HTML 文件本身不该长期缓存，否则用户可能看不到新版本页面；真正该长期缓存的是 JS、CSS、图片等静态资源，并配合文件名哈希或版本号更新机制。
为什么不能给 HTML 设置 long-term Cache-Control
HTML 通常是动态生成的（如 Laravel 视图、SSR 页面、PHP 模板），内容可能随用户状态、时间、权限实时变化。若设置 Cache-Control: public, max-age=31536000，浏览器会直接复用旧 HTML，跳过请求——连服务端逻辑都不走，导致菜单错乱、按钮失效、数据陈旧等问题。
常见错误现象包括：
- 修改了
index.html中的<script src="app.js">，但用户仍加载旧版app.js（因为 HTML 缓存了旧路径） - 发布新功能后，部分用户刷新页面无反应，需强制清缓存才能看到
- 在 Nginx 中对
/index.html配置了expires 1y，结果所有后续变更都不可见
HTML 应该用什么缓存策略
对 HTML 响应，推荐以下组合：
立即学习“前端免费学习笔记（深入）”；
-
Cache-Control: no-cache, must-revalidate：允许浏览器缓存，但每次都要向服务器发起条件请求（带If-None-Match或If-Modified-Since） - 或更保守地：
Cache-Control: no-store：完全禁止缓存（适合含敏感信息的后台页） - 若必须设短时效，可用
max-age=300（5 分钟），配合 ETag 让未变资源快速返回304
注意：Expires 头优先级低于 Cache-Control，且依赖服务器时钟，不建议单独使用。
html-to-pptx-converter
下载
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
静态资源怎么配才真正有效
JS/CSS/图片等资源可以且应该长期缓存，但前提是实现「内容不变 → URL 不变，内容一变 → URL 必变」。否则缓存再久也没用，用户照样卡在旧版本。
实操要点：
- 构建工具（如 Webpack/Vite）开启
contenthash，生成类似main.a1b2c3d4.js的文件名 - Nginx/Apache 对匹配
\.(js|css|png|woff2)$的路径统一加Cache-Control: public, immutable, max-age=31536000 -
immutable是关键：告诉浏览器“这个 URL 永远不会变”，可跳过后续的304验证，进一步提速 - 避免只靠
max-age却不改文件名——这是最常被忽略的坑
Service Worker + Cache API 要谨慎替代 HTTP 缓存
Cache API 不是 HTTP 缓存的升级版，而是另一套独立控制逻辑，适用于离线优先场景（如 PWA）。它无法替代服务器发的 Cache-Control，反而容易因代码 bug 导致资源永久卡死。
典型陷阱：
- 在
install事件中用caches.open('v1').then(cache => cache.addAll([...]))预缓存 HTML，结果 HTML 更新后 Service Worker 未更新，用户永远拿不到新版 - 忘记在
activate事件里清理旧缓存（caches.delete('v0')），导致磁盘占用持续增长 - 对非 CORS 资源（如本地
file://或 wkhtmltopdf 场景）调用cache.add()直接失败，没做 try/catch
除非你明确需要离线支持或自定义缓存路由逻辑，否则优先用好 HTTP 头 —— 它更稳定、更透明、调试更简单。
