这个坑最近特别多人踩——91网｜关于缓存设置的说法——难怪最近这么多人在问？现在的问题是：到底哪里变了

这个坑最近特别多人踩——91网｜关于缓存设置的说法——难怪最近这么多人在问？现在的问题是：到底哪里变了

近段时间，关于 91 网（或任何同类网站）“缓存不生效”“页面更新看不到”“静态资源反复被重新下载”之类的问题突然激增。很多人把矛头指向前端、浏览器或运营商，实际原因往往在配置链路中的某一环悄悄改了默认行为。下面把常见的变动、如何定位问题、以及稳妥的解决方案逐条拆开，方便你快速诊断并修复。

一、为什么突然这么多人遇到同样的问题？

• 后端或 CDN 的默认缓存策略被改动：许多托管/加速服务在更新时会改变“是否尊重源站 Cache-Control”、或把默认缓存 TTL 改得更激进/更保守。
• 自动构建/部署改了资产版本策略：队友不小心切掉了版本号，或把 build 输出改为覆盖同名文件，导致浏览器一直用缓存或一直强制重新下载。
• HTTP 头部或服务端中间件更新：安全插件、反向代理或框架升级后可能开始给 HTML 添加 Set-Cookie、或者把 Cache-Control 改成 private/no-cache。Set-Cookie 与某些 CDN 规则会让资源不被缓存。
• 浏览器或中间代理新策略：浏览器在某些条件下会更严格地处理缓存（例如 Service Worker、Vary/Accept-Encoding 变动），ISP/CDN 也可能加了缓存规则。
• HTTPS、域名或路径变更：从 http->https、或者添加/去掉 www，会导致缓存失效或被错误处理。
• 人为操作（误用 CDN 缓存清理、规则覆盖等）：有人清空了缓存或启用了错误的“忽略查询参数”设置。

二、先别慌——一套简单的排查流程 1) 用 curl 看响应头（最直接）： curl -I -L https://example.com/path/to/asset 观察 Cache-Control、Expires、ETag、Last-Modified、Vary、Set-Cookie、Age、Via 等字段。 2) 在浏览器 DevTools 的 Network 面板看实际请求结果：是否从 disk cache、memory cache、Service Worker 或 200/304/206 返回。 3) 检查 CDN 控制台：查看缓存规则、是否启用“遵循源站头部”或“覆盖源站 TTL”，是否存在自定义缓存规则（按路径/文件类型）。 4) 搜索最近的变更记录：CI/CD 配置、Nginx/Apache 配置、CDN 规则、第三方中间件或安全插件更新记录。 5) 验证是否因为 Set-Cookie 或 Cookie 导致缓存失效：静态资源响应带 Set-Cookie 会让某些代理/浏览器不缓存。 6) 本地对比：在不同网络（手机流量、公司网络、第三方线上检查工具）测试，判断是否为 ISP/边缘节点缓存问题。 7) 若使用 Service Worker，确认 SW 是否拦截并返回旧资源。

三、常见“坑”与诊断要点（针对性解决）

• 情形 A：HTML 页面总是 200（而不是 304），用户看不到新内容 诊断：查看 HTML 的 Cache-Control。若是 no-cache、private、max-age=0 或 service worker 返回固定缓存，说明源站或 SW 在控制缓存。 处理：HTML 可使用短缓存策略（例如 max-age=0, must-revalidate），并通过静态资源版本化保证 CSS/JS/图片长期缓存可安全更新。

• 情形 B：静态资源（.js/.css/.png）频繁 200 而非缓存命中 诊断：检查是否被 Set-Cookie、Vary（带 cookie/authorization）或 Cache-Control: no-store 覆盖。CDN 配置是否忽略查询字符串或不尊重源站头。 处理：确保静态资源响应带上 Cache-Control: public, max-age=31536000, immutable（同时采用文件名版本化）；在 CDN 中设置“按文件扩展名缓存”等正确规则。

• 情形 C：你改了资源文件名，但用户还是看到旧资源 诊断：CDN 未被清理，或浏览器使用了 Service Worker/HTTP 缓存。也可能是 HTML 中引用仍指向旧路径（部署问题）。 处理：启用版本化（文件名带 hash），并尽量避免使用 query string 作为唯一版本标识（部分 CDN 默认忽略）。部署流程里加入 CDN 自动清理或使用缓存失效 API。

• 情形 D：只有部分用户出现问题（地域/运营商差异） 诊断：边缘节点配置不一致或某些节点缓存规则被误改；ISP 的中间缓存行为不同。 处理：联系 CDN 支持检查边缘规则，或临时强制刷新边缘缓存；在关键页面降低缓存时长以便快速回滚。

四、具体实用配置示例（常见服务器）

• Nginx（静态资源长期缓存） location ~* .(?:css|js|jpg|jpeg|gif|png|svg|ico|woff2?)$ { add_header Cache-Control "public, max-age=31536000, immutable"; }

• Nginx（HTML 页面短缓存） location / { add_header Cache-Control "no-cache, must-revalidate"; }

• Apache（静态文件示例） Header set Cache-Control "public, max-age=31536000, immutable"

五、关于版本号/缓存清理的具体建议

• 静态资源采用文件名里直接带 hash（例如 app.abcdef123.js）比 query string 更稳妥。
• 对于必须立即生效的变更，使用 CDN 的清理 API（自动化脚本在部署流程里）而不是人工点击。
• HTML 保持短缓存或 no-cache，同时让 HTML 引用的静态资源使用长期缓存+hash，从而既能快速更新页面内容，又能享受静态资源缓存的好处。
• 对敏感数据/API 使用 Cache-Control: private/no-store 或在响应中带上 appropriate Vary/Authorization 规则。

六、如何快速定位“到底哪里变了” 1) 回顾最近一轮变更清单（CI/CD、框架、CDN、域名证书、代理或安全插件）。 2) 把问题归类（HTML 问题、静态资源问题、部分用户/全体用户），再对照上述“情形”去找对应头部、不一致配置或中间件。 3) 临时措施：把受影响资源短时间设置为 no-cache，以便快速恢复正常用户体验，修好后再恢复长期缓存策略。 4) 长期措施：把缓存策略写进代码/自动化部署，避免手工在控制台上改来改去造成不一致。

七、常见误解和容易被忽略的点

• “浏览器缓存就是前端问题”——很多时候是服务器或 CDN 在决定缓存策略。
• “query string 一定会缓存”——部分 CDN 有“忽略查询字符串”的选项，或者按规则不缓存带参数的资源。
• “ETag 总能解决一切”——ETag 有时候在多节点部署时不一致，会导致无意义的 200。使用一致化的缓存策略更可靠。
• Service Worker 一旦注册，可能彻底改变缓存行为。上线新 SW 时要有灰度和回滚策略。

八、结语与行动清单（3 步拿下） 1) 马上做的：用 curl 或 DevTools 检查异常请求的响应头，找出是否存在 Set-Cookie、Cache-Control 异常或 CDN 覆盖规则。 2) 中期改进：把静态资源文件名版本化，HTML 设置短缓存并确保部署自动触发 CDN 缓存清理。 3) 长期保障：把缓存策略写成可追踪的配置（源代码/基础设施即代码），并纳入部署流水线，避免人为误改导致的大规模波动。