nginx 通过 proxy_cache_path 的 inactive 参数自动清理静态资源缓存，依据最后一次访问时间而非创建时间，manager 进程周期扫描并安全删除超时条目；proxy_cache_valid 控制缓存响应逻辑，不决定物理删除。
Nginx 对静态资源的缓存过期清理，不依赖外部脚本或定时任务主动扫描，而是靠内置机制自动完成——核心是 proxy_cache_path 指令中的 inactive 参数，配合 proxy_cache_valid 控制逻辑有效期。只要配置得当，旧缓存会在无人访问后被 Nginx 自动、安全地回收。
inactive 是自动清理的关键
inactive 定义的是“最后一次被访问后多久未再命中，就可被删除”。它不是按文件创建时间或 HTTP 过期时间判断，而是基于实际访问热度。
例如：
proxy_cache_path /var/cache/nginx/static_cache levels=1:2 keys_zone=static_cache:20m max_size=500m inactive=2h; # ⚠️ 重点：2小时内没被任何请求访问过，就标记为可清理
Nginx 的 manager 进程会周期性（通常每几十秒）扫描缓存目录，把满足 inactive 条件的条目从磁盘删除，并同步更新内存中的 keys zone。这个过程完全异步、无额外开销，也不需要重启或 reload。
proxy_cache_valid 决定“是否返回缓存”，而非“是否删除”
该指令告诉 Nginx：哪些状态码可以缓存、缓存多久（覆盖后端响应头）。
proxy_cache_valid 200 301 302 1d; proxy_cache_valid 404 1m;
注意：即使一个响应已超过 proxy_cache_valid 设置的时间，只要它仍在 inactive 时间窗口内被频繁访问，Nginx 仍可能返回它（可能带 X-Cache: STALE 或触发后台校验）。真正触发物理删除的，始终是 inactive。
缓存 key 要简洁，避免碎片化
如果 proxy_cache_key 包含易变字段（如 $cookie_user, $arg_v, $http_user_agent），同一资源会生成大量不同 key，每个都要单独满足 inactive 才能删，大幅降低清理效率。
推荐写法：
proxy_cache_key $scheme$host$request_uri;
若需区分用户级内容，用 proxy_cache_bypass 跳过缓存，而不是扩大 key 范围。
不建议手动 rm -rf 缓存目录
直接删 /var/cache/nginx/* 会破坏 Nginx 内部索引（keys zone 与磁盘文件映射关系），可能导致后续缓存写入异常或命中率骤降。除非停服并重建缓存，否则应避免。
补充：让浏览器也及时更新，需配合前端策略
Nginx 层的 inactive 解决的是反向代理缓存（服务端缓存）的自动淘汰；而浏览器缓存需靠构建时加哈希（如 app.a1b2c3.js）+ 长 expires 实现真正零延迟更新。两者分工明确：
- 文件名不变 → 依赖
inactive+proxy_cache_valid管理服务端缓存 - 文件名带 contenthash → 浏览器天然跳过旧缓存，无需清理
不复杂但容易忽略
