TTL 决定缓存时长
TTL 决定资源在 CDN 边缘节点上能存活多久。带内容指纹的静态资源适合长 TTL，把回源降到最低；入口 HTML 与频繁变化的内容要用短 TTL，保证发布后访客尽快拿到新版本。TTL 的本质是回源压力与内容时效性之间的取舍，配错任何一边都会出问题：太短会压垮源站，太长会让变更迟迟不生效。
基本信息
| 生效优先级 | 源站 Cache-Control / Expires 与控制台缓存规则谁优先，各产品不同，改完必须实测 |
|---|---|
| 长 TTL 适用 | 带内容指纹的文件名、版本号固定的安装包、不常变的图片 |
| 短 TTL 适用 | 入口 HTML、列表页、频繁更新的数据文件 |
| 兜底手段 | 变更时用刷新强制失效，作为例外通道而非常规流程 |
典型使用场景
- 前端构建产物带 hash 文件名，配长 TTL 提升命中率
- 入口 index.html 配短 TTL，保证发版后引用指向新资源
- 活动页与运营素材按活动周期设置，活动结束后单独刷新
- 接口类响应默认不缓存，避免把个性化数据缓存给其他人
- 大文件下载按版本号命名，用长 TTL 减少回源带宽
检查实际下发头
检查实际下发头
curl -sI https://cdn.example.com/index.html | grep -i -E 'cache-control|expires|age|x-cache'
curl -sI https://cdn.example.com/assets/app.a1b2c3.js | grep -i -E 'cache-control|age'
# 连续请求两次，观察 Age 是否递增：递增说明命中了边缘缓存资源类型与建议
| 资源类型 | 建议 TTL | 理由 |
|---|---|---|
| 带指纹的 JS/CSS | 长 | 内容变则文件名变，无需靠刷新 |
| 入口 HTML | 短或不缓存 | 必须能及时指向新的资源清单 |
| 图片与字体 | 长 | 更新频率低，体积占比高 |
| 接口 JSON | 不缓存或极短 | 内容与用户或时刻强相关 |
边缘缓存时间从「用户真实取回该文件的时刻」开始计算，而不是源站的修改时间，所以同一文件在不同节点的过期时刻并不一致。
给入口 HTML 设长 TTL 又不做刷新，发布后访客会长时间停留在旧页面，甚至引用已被清理的旧资源导致白屏。