很多缓存问题并非出在缓存本身，而是出在缓存失效时间设置过于随意：商品页面更新了，用户仍看到旧内容；接口有效期过短，源站请求突然增加；浏览器已经更新，CDN 节点却还在返回旧文件。合理的配置应当同时考虑数据变化速度、内容敏感程度和失效后的回源能力。
一、先按数据类型确定有效期
设置过期时间前，先回答一个问题：内容允许延迟多久？不同数据不能套用同一个缓存策略。
| 内容类型 | 常见适用范围 | 主要注意事项 |
|---|---|---|
| 带版本号的图片、字体、安装包 | 数天至数月 | 文件名或路径更新后再发布新版本 |
| 新闻列表、活动页 | 几十秒至十几分钟 | 重大内容发布时应支持主动清理 |
| 商品价格、库存接口 | 数秒至约1分钟 | 不能只依赖自然过期，必要时主动删除 |
| 账户、订单、支付信息 | 通常不使用公共缓存 | 应区分登录状态和用户权限 |
例如，带哈希文件名的 JavaScript 文件通常可以使用较长有效期，因为文件内容变化时路径也会变化；而库存接口变化频繁，缓存时间过长可能造成下单判断失真。这里的关键不是追求最长时间，而是让缓存失效时间设置与业务容忍度一致。
二、配置前必须确认的四个边界
1. 明确缓存在哪里生效
浏览器缓存、反向代理、CDN 和应用内存缓存可能同时存在。只修改其中一层，不代表所有用户都会立即获得新内容。需要先画出请求路径，确认响应头由哪一层写入，以及上一层是否会覆盖下一层的 Cache-Control。
2. 检查缓存键是否完整
缓存键通常由请求路径、查询参数、主机名等信息组成。如果语言、地区、设备类型会影响返回结果，就必须纳入区分条件；如果某些追踪参数不影响内容，则可在进入缓存前清理。缓存键设计错误时，单纯调整有效期无法解决串内容问题。
3. 区分公共数据与私人数据
包含登录身份、收货地址、订单状态或账户余额的响应，不应直接作为公共缓存内容。可以只缓存页面外壳，再通过受控接口读取用户数据。对于同一接口，还要确认未登录和已登录请求不会共用一个缓存对象。
4. 评估过期瞬间的回源压力
缓存同时过期时，多个请求可能一起访问源站，形成“惊群”。源站连接数较小、数据库查询较重时，应考虑错峰过期、请求合并或短暂锁定回源。缓存系统使用 Redis 等集中式组件时，也要核实不同应用实例是否能访问同一份数据。
三、可执行的缓存失效时间设置步骤
- 列出资源清单。按页面、接口、图片、脚本和下载文件分类，记录更新频率、是否含用户信息、是否支持主动清理。
- 写出允许延迟。例如静态图片可接受数小时甚至数天，公告列表可能只接受几分钟，库存和支付状态则应采用更短时间或不缓存。
- 分别配置各层规则。在应用响应头、反向代理和 CDN 控制台中核对有效期，避免一层设置了较短时间，另一层又强制延长。
- 设计主动失效机制。商品修改、文章发布或配置变更完成后，按缓存键删除相关对象，而不是等待所有节点自然过期。
- 安排验证窗口。使用不同网络、不同登录状态和不同查询参数请求资源，检查响应头中的命中状态、年龄信息及内容版本。
如果团队缺少专人维护网络接入、主机或缓存链路，可在明确业务规则后咨询德讯电讯这类提供网络与服务器相关服务的厂商，重点确认其支持的缓存控制方式、日志能力和故障处理边界，不应只看宣传中的单一性能指标。
四、怎样判断设置是否合适
不要只看页面能否打开。建议在发布前后分别记录命中率、源站请求量、响应错误率和缓存对象年龄，并按资源类型拆分。观察时间可覆盖至少一个完整过期周期；对于高峰明显的业务，还应比较过期前后源站连接数是否突增。
常见异常包括：更新后仍返回旧版本，通常与多层缓存或主动清理遗漏有关；命中率很低，可能是查询参数过多、缓存键不稳定或容量不足；偶发串数据，则优先检查登录状态、地区和语言是否被错误合并。修改缓存失效时间设置后，应保留变更记录，写明旧值、新值、适用路径和回滚方式。
五、常见问题
缓存时间越长，性能一定越好吗？
不一定。长时间缓存能减少回源，但会增加旧数据持续存在的风险，适合变化慢且可通过版本号更新的资源。
只设置响应头就够了吗？
不一定。CDN、代理和应用可能各自有规则，还要确认是否存在强制缓存、缓存键改写或旧对象未清理。
为什么设置了短时间仍看到旧内容？
可能是浏览器、代理或 CDN 仍保留旧对象，也可能是发布请求没有覆盖实际访问的路径。应逐层查看响应头和缓存状态。
缓存失效后源站变慢怎么办？
可以降低集中过期的概率，增加请求合并或预热机制，并检查数据库查询、连接池和源站并发能力。
最终，缓存失效时间设置应服务于数据准确性与系统稳定性的平衡。先划分资源，再确定允许延迟，最后结合缓存键、主动清理和监控结果持续调整，才能避免只改一个数字却留下新的隐患。
