风向突然变了 | 91网｜关于缓存设置的说法｜我试了三种方法才搞明白！！别被带节奏，但也别装瞎

最近在91网上关于“缓存怎么设最好”的讨论炸开了锅。各种神操作、极端建议、互相反驳，看得我头都大了。于是我亲自动手，用三种不同方法在真实项目中反复验证，整理出一套能直接落地的做法和判断逻辑。把能立刻用的结论放前面，下面再说明来龙去脉和实操细节。

结论（快速上手）

• 静态资源（JS/CSS/图片）：使用长期缓存（Cache-Control: public, max-age=31536000, immutable） + 文件指纹（hash）做版本控制。这样性能最稳、CDN 加速最有效。
• HTML 与动态页面：短期或不缓存（Cache-Control: no-cache 或 max-age=0 + ETag/Last-Modified），或者采用 stale-while-revalidate 策略结合服务器端版本号推送。
• 登录/个性化接口：不要缓存到公共缓存（Cache-Control: private 或 no-store）。
• 验证方式：用 curl -I、浏览器 DevTools Network、以及 WebPageTest/GTmetrix 三管齐下测试变更是否生效。 不要只听某个帖子说“全部都长缓存”或“全部都不缓存”。任何极端都可能在某些场景里炸锅。

我试的三种方法（实战回顾） 方法一：一劳永逸式（把大部分资源都设长缓存）

• 思路：所有静态资源都设置一年缓存，省心省流量。
• 结果：静态资源命中率明显上升，首屏和重复访问速度很好。但如果没有严格做文件指纹，更新资源后用户会看到旧文件；强制刷新或改 URL 是唯一解决办法。
• 教训：长缓存必须配合版本化（hash 文件名）才能安全。

方法二：保守策略（HTML/资源都短缓存或不缓存）

• 思路：避免任何缓存问题，HTML、CSS、JS 都短缓存或 no-cache。
• 结果：每次请求都能拿到最新内容，便于调试和频繁发布。但牺牲了性能，重复访问流量和延迟明显增加。
• 教训：对小型站点或频繁改动的页面适用，但规模稍大就成本太高。

方法三：分层优化（推荐）

• 思路：区分静态与动态、公共与私有。静态走 CDN + 长缓存 + 指纹化；HTML 用短缓存或 ETag；个性化接口私有化。
• 结果：性能和可控性都达到平衡。部署复杂度适中，用户体验与运维成本都合理。
• 教训：这是现实中最常用也最稳妥的方案。

常见缓存头一览（只挑最常用的）

• Cache-Control: public, max-age=31536000, immutable — 适用于带指纹的静态资源。
• Cache-Control: no-cache, must-revalidate / max-age=0 — 适用于 HTML，允许缓存但每次需向服务器验证是否变化（通过 ETag/Last-Modified）。
• Cache-Control: private / no-store — 适用于带用户隐私的接口或登录后页面。
• ETag / Last-Modified — 辅助验证资源是否改变，配合 no-cache 或 max-age=0 使用效果好。
• Vary — 当根据不同请求头（如 Accept-Encoding）返回不同内容时要加上。

常见场景设置建议（实际可直接用）

• 网站静态资源（public、无登录关联）：
• Header: Cache-Control: public, max-age=31536000, immutable
• 发布时用文件名带 hash：app.abc123.js
• 首页、文章页（经常更新但非个性化）：
• Header: Cache-Control: no-cache, must-revalidate
• 或者 Cache-Control: max-age=0, stale-while-revalidate=30（如果支持）
• API（返回用户专属数据）：
• Header: Cache-Control: private, no-store
• CDN + 源站 配合：CDN 缓存静态资源，源站对 HTML 设置短缓存或 validation header。

实用命令与检查方法

• 查看响应头：curl -I https://example.com/path
• 检查是否命中缓存：打开浏览器 DevTools → Network，查看 Size/Status（304 / 200 from cache / 200 OK）
• CDN 工具：清理缓存后验证新版本是否传播；注意 TTL 和边缘节点刷新延迟。
• 性能测试：WebPageTest 或 Lighthouse 评估缓存策略对首次与重复访问的影响。

容易被带偏的几条“陷阱”

• “全部长缓存，省心” —— 如果没有版本化，会被旧资源困住。
• “全部不缓存，保证最新” —— 成本大、体验差，适合调试不适合生产。
• 盲目信任某个 CDN 的默认：很多项目需要按业务分层定制缓存策略。

落地清单（部署前最后检查）

1. 静态资源是否都做了文件指纹？没有，就不要一股脑设置超长 max-age。
2. HTML 是否需要即时可见？需要就用 no-cache/ETag，否则考虑短 TTL + stale-while-revalidate。
3. 登录/敏感数据接口是否设置 private/no-store？
4. 上线后用 curl 与 DevTools 验证头信息与实际行为是否一致。
5. CDN 缓存策略与源站一致，发布流程能自动触发缓存刷新或通过版本化规避。

结语 别被论坛上的单一声音带节奏：缓存既不是万能神药，也不是彻底毒药。按资源类型分层策略，配合文件指纹和正确的头部，能把性能、可控性和开发体验三者平衡好。要是你愿意，我可以根据你的网站技术栈（例如 Nginx、Apache、Cloudflare、Vercel、Netlify）给出具体配置示例。想要哪种？

本文标签： # 风向 # 突然 # 变了