缓存有效期需分层分类管理：html页max-age=600或no-cache，静态资源max-age=31536000，图片按场景设1h–24h，api原则上不强缓存；配套需失效闭环、命中监控与兜底容错。
缓存有效期不是拍脑袋定的，而是由资源稳定性、业务容忍度、更新频率和用户感知共同决定的。企业级标准不能一刀切，必须分层分类管理——静态资源可激进缓存，动态接口需严格控制，关键业务页则要兼顾一致性与性能。
按资源类型划分有效期基准
不同资源的变更节奏差异极大，硬套统一时间会引发数据陈旧或频繁回源：
-
HTML 页面（尤其是入口页、活动页）：建议 max-age=600（10分钟） 或使用
no-cache+ ETag/Last-Modified。页面常含动态模块（如倒计时、库存），过长缓存会导致用户看到过期状态。 -
CSS / JS / 字体 / 图标等静态资源：推荐 max-age=31536000（1年），配合内容哈希命名（如
app.a1b2c3.js）。这类文件一旦发布即不变，长期缓存可大幅降低重复请求。 - 图片（Banner、商品图、头像）：视业务场景而定。运营图建议 max-age=86400（24小时）；用户上传类图片（如头像）建议 max-age=3600（1小时） 或禁用强缓存，改用协商缓存（ETag）。
-
API 接口响应（JSON/XML）：原则上不设强缓存（
Cache-Control: no-store或max-age=0）。若确需缓存（如地区列表、配置中心），应控制在 max-age=300（5分钟）以内，并确保服务端支持If-None-Match校验。
按业务场景补充策略约束
技术规则需对齐实际业务逻辑，否则再标准也形同虚设：
- 营销活动页上线前，临时将对应路径缓存降为 max-age=60，避免用户卡在旧版落地页；活动结束立即恢复常规策略。
- 涉及金融、订单、账户余额等强一致场景，所有相关接口和页面必须禁用强缓存，强制每次校验服务端最新状态。
- 灰度发布期间，对带
X-Release-Version或Cookie: env=gray的请求，Nginx 应跳过缓存（proxy_cache_bypass $http_x_release_version;），确保灰度用户始终拿到新逻辑。
配套机制比时间值更重要
光写个 expires 1y 不代表缓存就可靠。企业级落地必须同步建设：
-
缓存失效闭环：静态资源发布后，通过 Webhook 触发 Nginx 缓存清理（
proxy_cache_purge）或 CDN 刷新，而非依赖过期被动淘汰。 -
缓存命中监控：在 Nginx 日志中记录
$upstream_cache_status（HIT/MISS/EXPIRED/STALE），实时看板跟踪各资源缓存健康度。 -
兜底容错配置：启用
proxy_cache_use_stale error timeout updating http_502 http_503，当上游异常时仍可返回旧缓存，保障核心链路可用性。
