inactive与max_size协同工作：inactive按时间标记冷数据，max_size在磁盘逼近上限时优先淘汰满足inactive条件的最久未访问条目；需分层配置并确保keys_zone足够大、use_temp_path=off以保障清理可靠性。
inactive 参数和磁盘配额（max_size）不是互斥选项，而是 Nginx 缓存清理机制中两个不同层级的“守门人”：inactive 管冷热，max_size 管总量。协同调优的关键，在于让它们节奏匹配、职责分明，避免互相抵消或留下清理盲区。
明确各自作用边界
inactive 决定“哪个缓存文件太久没被访问，可以删”——它按时间维度标记冷数据，由 cache manager 周期扫描执行，不立即删除，也不看磁盘是否快满。
max_size 决定“磁盘缓存最多占多少空间”——当实际占用逼近该值时，Nginx 会主动触发空间回收，并**优先淘汰满足 inactive 条件的最久未访问条目**。它不关心单个文件是否“过期”，只按冷热+时间排序做 LRU 式清理。
两者叠加后，缓存池实际行为是：既不会因长期不访问而堆积冷文件，也不会因突发流量写满磁盘而阻塞新缓存。
按业务热度分层设置 inactive，再绑定 max_size
不能所有资源用同一套 inactive + max_size。应根据内容访问特征分级配置：
- 高频接口响应（如用户中心 API、实时状态查询）：inactive=30m～1h，max_size=5g～10g。冷数据快速释放，避免旧状态滞留；小容量配额也够用
- 中频静态资源（如 JS/CSS/图片）：inactive=2h～6h，max_size=10g～30g。兼顾加载速度与磁盘压力，6 小时未访问基本可判定为临时热点衰减
- 低频长尾内容（如文档页、历史版本、PDF 归档）：inactive=7d～30d，max_size=20g～100g。允许冷数据驻留更久，但必须配足够大的 max_size，否则刚存几天就被 max_size 触发的 LRU 清理掉——那就失去了 inactive 的意义
注意 keys_zone 与 inactive 的隐性耦合
inactive 时间越长，共享内存中需长期保留的 key 元数据就越多。若 keys_zone 太小，冷 key 会被提前挤出内存，导致其最后访问时间无法追踪，inactive 就形同虚设。
例如：你设了 inactive=30d，但 keys_zone 只有 10m（约 8 万个 key），而实际活跃+冷 key 总数达 50 万——大量冷 key 的元信息早已丢失，cache manager 根本不知道它们“多久没被访问过”，自然无法按规则清理。
建议公式：keys_zone ≥ ⌈预估总 key 数 ÷ 8000⌉ MB × 1.2（留 20% 余量）。总 key 数包括你打算靠 inactive 保留的那部分冷 key。
配合 use_temp_path=off 提升清理可靠性
默认 use_temp_path=on 时，缓存先写入临时目录再 rename 到目标路径。cache manager 清理时可能遗漏重命名过程中的中间状态，造成“已标记删除但文件仍残留”。
设为 off 后，文件直落最终路径，inactive 计时准确，清理动作也更干净。这对依赖 inactive 自动瘦身的场景尤为重要。
