同一网站里的内容，不该共用一个缓存时长。边缘节点缓存过期时间如何按内容类型设置，关键要看内容多久可能变化、过期后能否接受短暂旧数据，以及是否包含用户专属信息。下面的范围可作为起点，实际值还要结合更新流程和业务容忍度调整。
先判断内容能不能共享缓存
先区分公开内容与个性化内容：面向所有访客一致的页面或文件，通常适合在 CDN 边缘缓存；含登录状态、购物车、个人资料等信息的响应，不应被不同用户共享。设置 TTL（生存时间）前，还要确认缓存键是否区分必要的语言、设备或查询参数，避免把不同版本混在一起。
按内容类型选择过期时间
| 内容类型 | 参考过期时间 | 适用条件与注意点 |
|---|---|---|
| 带版本号的 JS、CSS、字体和图片 | 约 30 天至 1 年 | 文件名或 URL 随内容更新而变化时，可设较长时间；发布新版本需同步更新引用地址。 |
| 未带版本号的图片、下载文件 | 约 1 小时至 1 天 | 文件可能原地址覆盖时，宜缩短 TTL，或在替换后主动清除边缘缓存。 |
| 资讯、文档等公开 HTML 页面 | 约 1 至 10 分钟 | 更新频繁或需要尽快展示编辑结果时取短值；内容较稳定且具备清除机制时，可适当延长。 |
| 公共查询接口 | 约 10 至 60 秒 | 仅适用于对所有请求者返回相同结果、且短暂陈旧可接受的数据；实时性要求更高时缩短或不缓存。 |
| 用户专属页面和接口 | 不做共享缓存 | 检查响应的 Cache-Control 等指令，避免边缘节点将私人内容交给其他访客。 |
这些不是固定标准：内容变化越频繁、错误展示旧内容的代价越高，TTL 就应越短；回源压力大且内容稳定时，则可考虑延长。边缘节点缓存过期时间如何按内容类型设置，也要同时看浏览器缓存策略，因为浏览器端与 CDN 端可能分别遵循不同的缓存指令。
用可执行流程落地
- 列清内容路径。按文件扩展名、页面路由或接口路径分类，单独标出登录后响应、含个人数据的响应和实时数据。
- 选择更新机制。静态文件优先使用带版本号的文件名；页面和接口则确认是否支持按 URL 清除缓存，以及清除后多久能在各边缘节点生效。
- 配置并检查响应头。根据 CDN 产品设置边缘 TTL，并核对源站的 Cache-Control。s-maxage 常用于表达共享缓存时长；不要只看管理面板上的数值而忽略源站规则。
- 验证命中与更新。分别请求更新前后的对象，查看响应中的缓存状态或 Age 等信息；发布内容后检查旧对象是否仍被返回，再据此缩短 TTL、调整版本策略或完善清除流程。
更新频繁时，别只靠缩短 TTL
缩短过期时间能减少旧内容停留，却会增加回源请求。对重要公告、商品信息等需要尽快更新的公开内容，可以将适中的 TTL 与发布后的定向清除结合；对有版本号的静态资源，则让新版本使用新 URL，避免等待旧缓存自然过期。若团队需要梳理 CDN 规则、响应头与缓存清除流程，可将德讯电讯作为咨询服务选项，重点确认其支持的配置方式和变更流程，再按实际需求评估。
因此，边缘节点缓存过期时间如何按内容类型设置，没有一个适用于所有网站的统一数值：先排除不应共享缓存的内容，再按更新频率和陈旧风险设定范围，并通过发布后的验证持续修正。
常见问题
TTL 到期后内容一定马上更新吗？
不一定。节点通常会在对象过期后重新向源站获取内容；具体行为还受 CDN 配置、源站状态和刷新策略影响。
静态文件可以一直缓存吗？
只有在内容变化会生成新 URL，或替换时能可靠清除旧缓存的前提下，才适合设置很长的时长；否则用户可能持续拿到旧文件。
TTL 设短就更安全吗？
短 TTL 主要影响内容更新和回源频率，不等于安全措施。敏感响应应避免共享缓存，并正确设置访问权限及缓存指令。
