nginx不存在“静态文件缓存描述符”概念，实际需区分浏览器端缓存（通过cache-control等响应头控制）和服务端proxy_cache缓存（由proxy_cache_valid和inactive共同管理生命周期）。
Nginx 中没有“静态文件缓存描述符”这个概念。它不维护类似操作系统文件描述符（file descriptor）那样的缓存句柄生命周期管理。你真正需要关注的，是两类独立但常被混淆的机制：浏览器端缓存控制和Nginx 服务端 proxy_cache 缓存条目管理。两者都不涉及“描述符”，而是围绕HTTP 响应头和缓存键+淘汰策略运作。
浏览器端缓存靠响应头驱动
Nginx 通过 add_header Cache-Control 或 expires 指令告诉浏览器“这个资源能存多久、是否可共享、要不要验证”。这不生成任何本地文件，也不打开或关闭文件描述符——只是注入标准 HTTP 头。
- 对带哈希的 JS/CSS（如
app.f3a7b2.js）：location ~* \.(js|css)$ { add_header Cache-Control "public, max-age=31536000, immutable"; }浏览器收到后，直接存入本地缓存，后续请求跳过网络，连 TCP 连接都不建。
- 对 HTML 或未哈希资源：
location ~* \.(html|php)$ { add_header Cache-Control "no-cache, must-revalidate"; }强制每次校验，避免展示陈旧骨架。
服务端 proxy_cache 条目靠 inactive + valid 联动淘汰
当 Nginx 作为反向代理缓存后端响应（比如 PHP 返回的 HTML），它会把响应体写入磁盘，并在内存 keys_zone 中记录 key → 文件路径映射。它的“生命周期”由两个参数共同决定：
-
proxy_cache_valid 200 10m;：告诉 Nginx “200 响应逻辑上最多缓存 10 分钟”，超时后若再被访问，可能触发后台校验（stale-while-revalidate）或返回过期副本； -
proxy_cache_path /path ... inactive=1h;：这才是真正的物理清理开关——manager 进程周期扫描，把最后一次被命中后超过 1 小时没再访问的缓存文件从磁盘删掉，并同步清理 keys_zone 中的索引。
这两个机制互不替代：valid 控制是否可返回，inactive 控制是否可删除。
不要试图“管理描述符”，要设计好 key 和淘汰边界
如果你发现缓存积压、磁盘涨满或命中率低，问题通常出在：
-
proxy_cache_key包含易变字段（如$cookie_session或$arg_ts），导致同一资源生成大量 key，每个都得单独满足inactive才能删； -
inactive设得太长（如7d），而实际流量稀疏，旧文件长期滞留； - 没配
proxy_cache_valid，Nginx 默认只缓存 10 秒，频繁回源，inactive根本没机会触发清理。
真正有效的做法是：
- 静态资源走
root/alias + Cache-Control，不启用proxy_cache； - 动态内容走
proxy_pass + proxy_cache，key 精简（去掉用户态变量），inactive设为业务真实冷热周期（如 30 分钟～2 小时）； - 清理需求明确时，用
proxy_cache_purge精准失效，而不是等自动淘汰。
不复杂但容易忽略。
