边缘缓存 TTL 设置如何平衡内容更新与命中率，关键不是把时间统一设长或设短，而是先确认内容允许陈旧多久，再选失效方式。页面几分钟内变化一次，与带版本号的图片，适合采用完全不同的缓存策略。
以下五种做法可单独使用，也可以组合。文中的时间范围是常见起点，不是固定标准；实际效果还受 CDN 配置、访问频率、缓存键和源站响应头影响。
先分清两个时间：TTL 与可接受陈旧时间
TTL 是对象在边缘节点保持新鲜的时长。过期后，节点可能回源验证、重新获取，或在特定规则允许时继续提供旧内容。它不一定等于内容从发布到所有用户看到更新的时间：不同节点的请求和失效方式会造成差异。
设置前，分别给内容定义两个条件：一是最长可接受的更新延迟；二是源站能承受的回源量。前者决定 TTL 上限，后者影响 TTL 能否设得更短。HTTP 缓存响应头中的 s-maxage 用于共享缓存，max-age 通常用于浏览器及其他缓存；具体 CDN 是否遵循、覆盖或忽略这些指令，应检查对应配置。
比较五种 TTL 策略
1. 固定 TTL：配置简单，适合内容稳定的对象
所有匹配对象使用同一个时长，例如设置为 10 分钟。这种方式规则少、容易排查，适合更新频率相近、陈旧影响较小的内容。缺点是无法照顾差异：频繁变动的页面可能更新偏慢，稳定资源则可能过早回源。
2. 按内容类型分层：以差异换取更合适的命中率
按 URL 路径、文件类型或业务标签设置规则。例如，公告列表可从数分钟开始试调；较少变化的说明页可从数十分钟到数小时评估；带内容哈希或版本号的 CSS、图片等静态资源，若文件名随内容改变，可设置数天至约一年，并在发布新版本时更新引用地址。
这种策略通常比单一 TTL 更贴合内容特征，但分类规则必须准确。若动态页面被错误匹配到长缓存规则，用户可能长时间看到旧数据。
3. 高频内容设短 TTL：以回源换取更快更新
对几分钟内可能变化、又不具备可靠清除流程的内容，可从 30 秒至 5 分钟一类的短区间开始评估。短 TTL 能缩短自然过期等待时间，但访问量高时会增加回源请求；低流量对象还可能在过期后很久才有人触发更新。若内容必须接近实时，缓存未必是合适的主要交付方式。
4. 较长 TTL 配合发布清除：更新快，依赖失效流程可靠
发布内容后主动清除相关缓存，可让对象平时保持较长 TTL，同时在更新时尽快重新获取。适合发布频率可控、能明确定位受影响页面或资源的场景。风险在于清除范围遗漏、操作延迟或失效失败；应保留合理 TTL 作为兜底，并验证清除是否覆盖正确的缓存键与路径。
5. 允许短暂复用过期内容：在更新与可用性间折中
支持相关指令的缓存系统可以在对象过期后，先提供短时间的旧内容并在后台更新；源站暂时不可用时，也可在设定窗口内复用旧副本。HTTP 中常见的 stale-while-revalidate 和 stale-if-error 指令用于表达这类意图，但支持情况取决于边缘服务配置。此法可减少等待或突发回源，代价是用户可能短暂看到旧内容，不适合必须严格反映最新状态的数据。
按这四步确定初始值
- 列出对象和更新要求：区分页面、接口响应和静态文件，记录每类可接受的陈旧时间，例如“数分钟内可更新”或“必须发布后立即变化”。
- 选择失效机制：能准确执行发布清除的内容，考虑较长 TTL 加清除；清除不可靠的内容，则按可接受延迟设置较短 TTL；不可陈旧的内容不应仅依赖缓存过期。
- 检查缓存键：确认会影响响应的查询参数、语言、设备差异等是否纳入缓存键。无关参数若被纳入，可能拆散缓存；必要参数若被遗漏，则可能让不同请求错误共用响应。
- 小范围观察并调整：先对一类路径试运行，检查缓存命中率、回源请求、内容更新时间和错误情况。命中率低时，先查规则是否命中、缓存键是否过宽或对象是否频繁变更，再决定是否延长 TTL。
因此，边缘缓存 TTL 设置如何平衡内容更新与命中率，应以内容的陈旧容忍度为先，再用命中与回源数据校正参数。不要仅为提高命中率而延长所有对象的缓存时间。
常见问题
TTL 越长，命中率一定越高吗？
不一定。访问频率低、缓存键分散或对象经常被清除时，延长 TTL 未必明显提高命中率，还可能延长旧内容的可见时间。
更新后为什么仍有人看到旧内容？
浏览器、边缘节点和上游代理可能各自缓存；也可能是清除范围不完整，或不同请求使用了不同缓存键。应逐层检查响应头和缓存规则。
静态资源可以设置很长 TTL 吗？
如果内容变化时会生成新文件名或版本号，长 TTL 通常更稳妥；若文件名不变，则需要清除旧缓存或采用较短 TTL，避免用户持续获取旧文件。
怎么判断 TTL 该延长还是缩短？
先看更新延迟是否超过业务容忍范围，再看缓存命中率和回源压力。更新可接受且回源偏多时可谨慎延长；旧内容影响明显时应缩短或改用发布清除。
