实现“热点数据永不过期”的常驻缓存，核心是禁用proxy_cache_valid、调大inactive时间并保障访问频次，配合主动purge更新与命中率监控，而非依赖expires max或open_file_cache。
实现“热点数据永不过期”的常驻缓存，在 Nginx 中不能靠设置 expires max 或 proxy_cache_valid 为极大值来达成——因为那只是“过期时间长”，不是“永不过期”；真正的永不过期需结合缓存机制类型、资源特性与运维配合，核心在于：**不设自动过期，但确保内容稳定、更新可控、命中率高**。
一、区分缓存类型：静态文件 vs 代理缓存
“永不过期”在不同缓存场景下含义不同，必须先明确你缓的是什么：
-
静态资源（如 JS/CSS/图片）：不适用“永不过期”概念。浏览器缓存必须设
expires max+immutable，但前提是资源 URL 带哈希（如app.a1b2c3.js）。URL 不变而内容变，就会锁死旧版本——这不是缓存策略问题，是发布流程缺陷。 -
反向代理缓存（proxy_cache）：这才是可真正实现“永不过期”的场景。Nginx 的
proxy_cache_valid默认不设时，缓存项不会因时间自动失效；只要不触发inactive清理或手动清理，它就一直留在磁盘+内存元数据区中。
二、proxy_cache 实现事实上的永不过期
关键不是“不让它过期”，而是“不让它被删”。需同时满足以下三点：
-
不配置
proxy_cache_valid：省略该指令，Nginx 就不会基于响应状态码自动设 TTL；缓存项仅受inactive和磁盘空间约束。 -
调大
inactive时间并保障访问频次：例如inactive=30d，意味着该缓存项 30 天内至少被命中一次，就不会被缓存管理器自动淘汰。 -
避免触发主动清理条件：不使用
proxy_cache_bypass/proxy_no_cache，响应头中不带Cache-Control: no-store或Set-Cookie（除非显式允许）。
三、配套保障：让“永驻”真正可靠
光靠配置不够，还需业务侧协同：
- 热点识别要准：只对真正高频、低更变的接口启用，比如首页聚合数据、商品类目树、地区编码表。不要全量开启。
-
更新必须主动穿透：数据变更时，必须同步执行
proxy_cache_purge（需启用ngx_http_proxy_cache_purge_module）或通过curl -X PURGE清除对应 key，而非等待缓存自然过期。 -
监控缓存命中率与存活时长：用
$upstream_cache_status日志字段统计 HIT/MISS/EXPIRED；定期检查proxy_cache_path目录下文件的 mtime，验证是否长期未更新。
四、为什么不推荐 open_file_cache 做“永驻”？
open_file_cache 缓存的是文件句柄和元数据（stat 结果），不是文件内容本身。它没有“过期”概念，只有 inactive 淘汰逻辑。但它无法保证“常驻”：
- 系统级限制（如 ulimit -n）可能强制关闭空闲 fd；
- Nginx reload 会清空整个 cache；
- 它不解决内容更新问题，只加速读取——适合静态资源服务层优化，不是业务热点数据缓存方案。
