inactive参数专为清理低频冷数据设计，不依赖Cache-Control或proxy_cache_valid，而是由cache manager周期扫描，依据最后一次命中后闲置时长决定是否删除；需合理设置值并匹配keys_zone大小，与max_size协同实现两级空间回收。
inactive 参数不是控制缓存“是否过期”，而是决定缓存文件在磁盘上“能躺多久没人管”。它专为清理低频访问的冷数据而设，配合 max_size 和 keys_zone，构成 Nginx 缓存空间自管理的核心逻辑。
inactive 的真实作用机制
它不看响应头里的 Cache-Control，也不管你设了多长的 proxy_cache_valid。Nginx 的 cache manager 进程会周期性扫描磁盘缓存目录，对每个缓存条目检查：
- 该条目最后一次被成功返回给客户端（即 HIT）是什么时候？
- 从那次命中起，是否已连续超过 inactive 设定的时间未被再次访问？
- 当前是否没有请求正在使用它（非 active 状态）？
三项都满足，就标记为可删除。哪怕 max-age 还剩 59 分钟，只要 inactive 到期，照样清。
设置 inactive 值的关键原则
值太小会误删，太大则积压冷数据。需结合业务访问特征来定：
- 静态资源（JS/CSS/图片）：推荐 1h～6h。新上线页面可能首访后隔几分钟才二次访问，低于 10 分钟易丢
- 动态接口（如用户配置、列表页）：30m～2h 更稳妥，更新较频繁但重复请求集中
- 归档类内容（PDF、旧文档、历史 API）：可设为 24h、7d 甚至 30d。每月查一次的文件，设 7d 就能稳留，设 1h 就每次都要回源
必须同步调优 keys_zone 大小
inactive 要生效，前提是缓存键（key）和它的最后访问时间能长期驻留在共享内存中。如果 keys_zone 太小，key 元信息被挤出，Nginx 就“忘了”这个缓存上次啥时候被访问过，inactive 就形同虚设。
估算公式：1 MB keys_zone ≈ 存储 8000 个唯一 key（含元数据）。例如预期有 40 万个活跃缓存项，建议 keys_zone ≥ 50m（400000 ÷ 8000 = 50），再加 20% 余量更稳妥。
常见误区：keys_zone 不是越大越好。超过 200m 可能引发内核 slab 分配延迟；低于 10m 容易导致 key 频繁淘汰，使 inactive 失效。
与 max_size 协同实现两级空间回收
inactive 是第一道自动清理策略，max_size 是兜底硬限制：
- 当磁盘缓存总大小逼近 max_size 时，Nginx 会优先按 inactive 规则，从“最久未被访问”的条目开始删
- 即使没到 max_size，只要某个缓存项闲置超 inactive 时长，且无活跃引用，也会被清理
- 两者搭配，既能防冷数据堆积，又能防磁盘爆满。比如配置 inactive=7d max_size=2g，就是让缓存只保留最近一周有热度的内容，总量不超过 2GB
