nginx worker 进程不执行缓存淘汰，仅负责请求处理、缓存命中判断及元数据读写；淘汰由 cache manager 和 cache loader 进程协同完成，worker 仅通过访问刷新 atime 以维持缓存活性，淘汰动作完全异步、后台化。
Nginx 的 Worker Process 不直接执行响应缓存淘汰，它只负责处理请求、读写缓存元数据、命中判断和响应返回。真正的缓存淘汰由独立的 cache manager 进程（缓存管理器）和 cache loader 进程（缓存加载器）协同完成，Worker 进程仅配合其机制被动参与。
以下是关键逻辑和协作方式：
淘汰决策不由 Worker 做主
Worker 进程在服务请求时，会检查缓存项是否“逻辑过期”（依据proxy_cache_valid）或是否“冷数据”（依据inactive时间）。但它不会主动删除文件；它只标记该缓存为“可淘汰”，并依赖 cache manager 定期扫描清理。inactive是淘汰的核心触发条件proxy_cache_path中设置的inactive=24h表示：任意缓存项若连续 24 小时未被任何 Worker 进程访问（即无hit或revalidate），则被 cache manager 视为过期冷数据，从磁盘删除。
注意：这个时间与响应头里的Cache-Control或Expires无关，也与proxy_cache_valid设置的“逻辑有效期”不同步——即使内容逻辑上仍有效，只要没人访问，就会被清掉。Worker 在访问时刷新
inactive计时器
每次 Worker 成功命中一个缓存项（$upstream_cache_status = HIT），就会更新该缓存文件的atime（访问时间），从而重置inactive倒计时。这依赖于文件系统支持atime（默认开启），且 Nginx 需要能读写该时间戳。淘汰动作由 cache manager 异步执行
cache manager 进程周期性（默认每 200ms 扫描一次）遍历缓存目录，比对每个缓存文件的atime与当前时间差。若超过inactive时限，就 unlink 对应文件，并从共享内存keys_zone中移除元数据条目。整个过程对 Worker 透明，不影响请求处理。max_size触发 LRU 式强制淘汰
当缓存总大小逼近max_size（如max_size=2g），cache manager 会按“最后访问时间”排序，优先删除最久未访问的文件，直到空间回落到阈值以下。这也是 Worker 不参与、纯后台行为。
简言之：Worker 负责“用缓存”，不负责“删缓存”；它通过访问行为维持缓存活性，而清理工作完全交给专用后台进程，保障高并发下主线程不被 I/O 或扫描阻塞。
