有人整理了一份避坑清单：91官网｜关于缓存设置的说法；越往下越离谱…？评论区已经吵翻了
有人整理了一份避坑清单：91官网｜关于缓存设置的说法；越往下越离谱…？评论区已经吵翻了
导语 最近一则关于“91官网缓存设置”的帖子火了：有人把从官方论坛、开发群和评论区搜集来的缓存建议汇总成一份避坑清单，越往下越离谱，评论区瞬间炸开了锅。本文把关键观点拆解成可执行的避坑清单，顺带澄清那些容易误导人的说法，方便站点维护者、前端工程师和站长快速判断与落地。
一眼看清楚：核心结论
- 静态资源（图片、JS、CSS）宜长期缓存并搭配版本号或指纹（cache-busting）。
- HTML 页面通常不宜长时间缓存，除非配合服务器端或 CDN 做内容失效策略。
- 盲目套用“所有资源缓存一年”、“关闭 ETag”之类的极端做法可能造成内容不同步或调试难题。
- 缓存策略需要根据资源类型、更新频率和分发方式（CDN/直连）分别制定。
避坑清单（可直接执行） 1) 区分资源类型并设置不同策略
- HTML：Cache-Control: no-cache 或 max-age=0, must-revalidate，配合 ETag/Last-Modified 做条件请求。
- 静态资源（带指纹）：Cache-Control: public, max-age=31536000, immutable。
- 第三方脚本：视信任度与更新频率短期缓存或不缓存。
2) 使用版本号/指纹避免强缓存问题
- 每次发布前对关键静态资源（app.js、style.css、图片）生成指纹（hash），引用文件名随之改变。
- 有了指纹，可以放心把长缓存时间交给浏览器和 CDN。
3) CDN 配置要和源站策略一致
- CDN 上的缓存规则优先于浏览器。发布后清理或通过版本号替换可以避免频繁清 CDN 缓存带来的问题。
- 对动态页面使用缓存键和缓存规则细化（cookie、query string 控制）。
4) 合理使用条件请求（ETag/Last-Modified）
- 保留 ETag 或 Last-Modified 用于减量传输，避免每次都下载完整资源。
- 不要把 ETag 直接关闭作为“性能优化”的万能手段——跨服务器部署时要注意 ETag 不一致会导致缓存失效。
5) 自动化发布流程里加入缓存策略
- 构建流程自动生成资源指纹；部署脚本在发布前后自动清理 CDN/触发失效。
- 回滚策略也要考虑资源 URL 的兼容性，避免用户访问到混合版本导致错误。
常见“越往下越离谱”的说法与真相
-
说法：所有资源都设置 Cache-Control: max-age=31536000，省事。 真相：短期看似省事，长期会让发布的更新无法及时生效，除非每次都改文件名或清 CDN 缓存。
-
说法：关闭 ETag 就能提升性能。 真相：关闭 ETag 只是在规避不一致问题，但同时失去条件请求带来的带宽节省。更好的做法是统一 ETag 策略或使用 Last-Modified + 强指纹策略。
-
说法：页面也能像静态资产那样长期缓存。 真相：页面通常需要根据用户状态/权限/内容实时生成，应以短缓存或 no-cache 为主，再通过边缘缓存策略优化。
技术参考示例（常见 Header 配置）
-
静态资源（已指纹）： Cache-Control: public, max-age=31536000, immutable
-
HTML 页面（需实时校验）： Cache-Control: no-cache, must-revalidate ETag: "abcdef123456" 或 Cache-Control: max-age=0, must-revalidate
-
图片短期缓存示例（频繁更新场景）： Cache-Control: public, max-age=3600
如何在实际中权衡
- 先梳理资源清单（哪些是用户可见的动态内容，哪些是静态文件）。
- 对静态文件走指纹+长缓存，对动态内容走短缓存或条件请求。
- 使用 CI/CD 把缓存规则纳入发布流程，必要时自动触发 CDN 缓存清理或更新版本号。
- 在上线前通过 Lighthouse、WebPageTest 等工具检测缓存策略对加载性能和刷新行为的影响。
结语 评论区吵翻的原因大多不是因为大家都错，而是不同场景下的建议被断章取义后混用。把“缓存”从万能钥匙变成可配置的工具，按资源类型和发布流程来制定规则，才能既保障性能也保持可维护性。欢迎把你在生产环境遇到的缓存“坑”或离谱建议发到评论区，一起把清单完善得更接地气。