缓存 · 排查路径

Cache-Control 配置实践

Cache-Control 应按响应是否个性化、更新频率和托管缓存的实际行为设计。Cookie 或登录状态本身不等于共享缓存一定安全。

排查步骤

查看、判断、复查

  1. 01

    审查每类响应(HTML、API、静态资源、用户私有数据)的策略是否匹配敏感度。

  2. 02

    个性化响应通常应使用 private;需要每次复核新鲜度时使用 no-cache。只有在确实不应被任何缓存保存时才使用 no-store。

  3. 03

    静态资源若使用内容哈希或版本化 URL,可设置较长缓存期;具体指令仍要与所用 CDN 的配置一起验证。

  4. 04

    检查 ETag、Last-Modified 与 Cache-Control 的交互,并用相同请求条件观察浏览器和 CDN 的实际响应。

跟着示例核对

示例内容用于说明方法,非本站探测记录。复核于 2026-10-03。

模拟响应,非本站探测;2026-10-03 09:00 +08:00,同一客户端与 GET 条件
A 公开页面,无 Cookie 或 Authorization
HTTP/1.1 200 OK
Cache-Control: public, max-age=60, s-maxage=600
ETag: "release-b"
Age: 120

B 个人账户响应
HTTP/1.1 200 OK
Cache-Control: private, no-cache
ETag: "account-example"

Date、请求发送/接收时间及实际缓存节点:未取得

怎样解释结果

A 的 max-age 适用于未被覆盖的缓存新鲜度;共享缓存使用 s-maxage=600。Age=120 不足以算出精确剩余时间或断定具体节点命中。B 的 private 限制共享缓存保存,no-cache 要求再次使用前验证;它与禁止保存的 no-store 含义不同。

不符合预期时

将 A、B 的响应头分别粘贴到缓存文本工具,核对字段解释和未知项;工具不发请求、不判定命中。个人数据若意外配置 public/s-maxage,先停止扩大变更并核对实际缓存规则与已存数据处置;缺少验证器或出现冲突指令时,记录待查项,不凭头文本宣布安全。

修改后复查

在自己的环境保存相同 URL、Cookie/认证条件、请求头、正文版本和时间,区分浏览器私有缓存与 CDN 共享缓存;验证个性化响应不会跨用户复用。按实际部署规则复查,结果不符合预期则回退;文本解读完成不代表缓存配置已修复。

分别解读示例 A 与 B 的缓存响应头 →