缓存规则决定什么
缓存规则回答三个问题：哪些请求会被缓存、缓存多久、按什么条件匹配。常见做法是按目录、按文件后缀或全站配置——静态资源设长缓存，动态接口不缓存。规则之间还有优先级关系，先匹配到哪条就按哪条执行，所以配置完成后必须抽查多条路径，确认它们命中的是预期规则，而不是统统落进默认规则里。
常见规则配置
| 维度 | 示例 | 说明 |
|---|---|---|
| 目录 | 静态目录缓存 30 天 | 按路径前缀匹配 |
| 文件类型 | 图片与样式脚本缓存 7 天 | 按后缀匹配 |
| 动态路径 | 接口路径不缓存 | 每次回源取最新 |
| 默认规则 | 其余按默认 TTL | 避免漏配置路径 |
基本信息
| 匹配维度 | 路径、后缀、文件类型等 |
|---|---|
| 优先级 | 按产品规则比较，先命中先执行 |
| TTL | 决定缓存保留时长，越长回源越少 |
| 验证 | 看响应头中的缓存状态与 Age |
典型使用场景
- 静态资源长缓存，减少回源并提升用户加载速度
- 接口与登录态相关路径不缓存，避免返回陈旧数据
- 按业务目录分别设置 TTL，图片与脚本用不同策略
- 新规则上线后抽查各类路径，确认命中预期的不是默认规则
验证规则命中
验证规则命中
curl -sI https://cdn.example.com/static/app.js \
| grep -i -E 'cache-control|x-cache|age'
curl -sI https://cdn.example.com/api/user | grep -i -E 'cache-control|x-cache'
# 对比两条路径，确认静态命中缓存、接口未缓存新规则上线后抽查多条路径，确认命中预期规则而不是落进默认规则。
TTL 怎么定才合理
TTL 的取舍是「回源压力」与「内容新鲜度」之间的权衡：TTL 越长回源越少、源站压力越小，但内容更新后需要刷新才能生效；TTL 越短内容更新更快，代价是回源请求变多。实用策略是给带版本号或内容哈希的静态资源设很长的 TTL，因为它们更新时 URL 会变，不会被旧缓存影响；HTML 入口这类固定 URL 设较短的 TTL 或按需刷新。这样既压低了回源比例，也不会让用户长时间看到旧内容。