Nginx缓存清理由第三方模块触发，调用ngx_http_file_cache_purge基于内存索引查找entry，count为0时删除；未命中则暴力扫描目录比对MD5 key，全程受cache锁保护并同步更新共享内存状态。
阅读 Nginx 源码中缓存清理逻辑（ngx_http_file_cache_purge）的关键，是理清它在什么时机被调用、由谁触发、如何定位并安全删除缓存文件。它不是独立模块，而是嵌套在 ngx_http_file_cache.c 中的一组辅助函数，依赖于缓存索引结构和文件系统操作。
明确 purge 的触发路径
缓存清理不通过 HTTP 请求直接执行（Nginx 官方不提供内置 purge 接口），而是由第三方模块（如 ngx_cache_purge）或自定义 handler 调用。典型流程为：
- 收到匹配的 purge 请求（例如
GET /purge/xxx）→ 第三方模块解析 URI → 提取待清理的 cache key - 调用
ngx_http_file_cache_lock获取 cache 共享锁，避免并发清理冲突 - 调用
ngx_http_file_cache_manager或直接调用ngx_http_file_cache_purge核心逻辑 - 最终调用
ngx_http_file_cache_delete执行物理删除
聚焦核心函数 ngx\_http\_file\_cache\_purge
该函数本身不直接遍历磁盘，而是基于内存中的 cache manager 数据结构快速定位目标缓存节点：
- 输入参数为
ngx_http_request_t *和待 purge 的ngx_str_t *key - 先调用
ngx_http_file_cache_find尝试查找已缓存的 entry（注意：它只查内存 hash 表，不读磁盘） - 若找到且状态有效（
entry->count == 0，即无活跃 reader），则调用ngx_http_file_cache_delete - 若未命中内存表，则需回退到暴力扫描（见下一点）
理解“暴力清理”机制（fallback scan）
当 purge key 不在内存索引中（例如缓存刚写入但尚未被 manager 加载，或 key 哈希冲突漏查），部分实现会启用目录扫描：
- 遍历 cache path 下所有二级子目录（
levels=1:2对应 256×65536 个目录） - 对每个
cache file读取其 header（前 512 字节），解析出存储的 key 和 valid time - 比对 key 的 MD5 值（Nginx 默认用 MD5(key) 作文件名），匹配则 unlink
- 此过程开销大，生产环境应避免频繁触发；可通过预热或 key 设计减少漏查
注意锁与生命周期管理
purge 不是原子操作，需关注并发安全：
-
ngx_http_file_cache_lock/unlock保护共享内存中的 cache manager 结构 - 删除前检查
entry->count：非零表示仍有请求正在读该缓存，此时仅标记为deleting，等 count 归零再真正 unlink - 物理删除后需同步更新共享内存中对应 slot 的状态（置为
NULL或重置valid字段） - 若使用
proxy_cache_lock on，purge 可能阻塞后续请求，需评估业务容忍度
不复杂但容易忽略。重点盯住 key 查找路径、锁作用域、以及 delete 前的引用计数判断，就能抓住 purge 的主干逻辑。
