Nginx 通过 inactive 参数自动清理冷缓存，即缓存项最后一次访问后闲置超时即删，无需脚本或定时任务；proxy_cache_valid 仅控制缓存可用性而非删除；精简 cache_key 和 PURGE 接口可辅助管理。
Nginx 本身不主动扫描“过期时间”来删缓存文件，真正决定物理删除的，是 inactive 参数——它看的是缓存项最后一次被访问后，是否已闲置超过设定时长。只要没被再访问过，哪怕响应本该缓存7天，24小时内没命中也会被自动清理。
靠 inactive 实现自动淘汰冷缓存
这是最核心、最省心的机制，无需脚本、不依赖定时任务，由 Nginx manager 进程后台异步完成：
- 配置示例：proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:10m max_size=2g inactive=24h;
- 含义：任意缓存条目，只要连续24小时没被任何请求命中，就会被安全删除（包括元数据和内容文件）
- manager 进程默认每几十秒扫描一次，无性能开销，也不需 reload 或重启
用 proxy_cache_valid 控制“是否可用”，而非“是否删除”
这个指令只影响 Nginx 决定返回缓存还是回源，和磁盘清理无关：
- 例如：proxy_cache_valid 200 301 302 10m; 表示状态码为200/301/302的响应，逻辑上最多缓存10分钟
- 但若该缓存10分钟后仍被频繁访问，Nginx 可能返回
X-Cache: STALE并后台校验，或直接继续用（取决于是否配了proxy_cache_revalidate） - 真正触发删除的，永远是
inactive时间窗口是否超时
精简 cache_key，避免缓存碎片化
如果 key 设计太细（比如混入 Cookie、时间戳、随机参数），同一资源会生成多个缓存副本，每个都要单独满足 inactive 才删，导致旧缓存长期残留：
- 推荐写法：proxy_cache_key $scheme$host$request_uri;
- 避免写法：proxy_cache_key "$scheme$host$request_uri$cookie_session$arg_ts";
- 统一 key = 统一淘汰路径，让
inactive发挥全局效力
配合 PURGE 接口做紧急人工清理
当需要立即下线某条内容（如误发公告、敏感信息撤回），可启用 ngx_cache_purge 模块：
- 确认模块已编译：
nginx -V 2>&1 | grep cache-purge - 配置 location：
location ~ /purge(/.*) {
allow 127.0.0.1;
proxy_cache_purge my_cache $scheme$host$1;
} - 执行清理：
curl -X PURGE http://localhost/purge/api/v1/news/123
