缓存条目通过inactive淘汰和valid校验双重机制移除：非活跃文件在inactive时间内未被访问即标记待清理；valid周期内主动stat检查，发现元数据不一致则立即更新或失效。
open_file_cache 不是内容缓存，它只缓存文件元数据和句柄（如是否存在、大小、修改时间、权限、fd），失效与更新机制围绕“状态一致性”设计，核心靠 inactive 淘汰 + valid 主动校验 + inotify 事件驱动 协同工作。
缓存条目何时被移除？
缓存项不会永久保留，淘汰由两个独立机制控制：
-
非活跃淘汰（inactive）：某文件在指定时间内（如
inactive=60s）未被任何请求访问，该条目会被标记为待清理，不参与后续查找 -
主动验证失效（valid）：Nginx 每隔
open_file_cache_valid秒（如 30s）遍历当前缓存，调用stat()检查文件是否仍存在、mtime 是否变化、权限是否有效；若发现不一致，立即更新缓存中的元数据
文件更新后，缓存能及时感知吗？
取决于配置组合和系统支持：
- 启用
open_file_cache_events on;（推荐）：依赖内核 inotify 监听文件变更，一旦源文件被覆盖或重写，Worker 进程实时收到通知，立刻刷新对应缓存项 —— 这是最灵敏的方式 - 未启用 events 或 inotify 不可用：仅靠
valid周期轮询检测。例如valid=30s，则最多延迟 30 秒才能发现文件已更新 - 注意：
inactive时间越长，旧缓存停留越久；若inactive=300s但valid=30s，文件虽被频繁访问，仍会在 300 秒后因“非活跃”被清除，不影响更新感知
错误状态也会被缓存，怎么避免误判？
open_file_cache_errors on; 会把 404、403 等结果也存入缓存，防止恶意扫描反复触发磁盘查询。但它必须配合 valid 才有意义：
- 若文件原为 404，后来被上传，缓存中的“不存在”状态不会自动消失，需等待下一次
valid检查时发现文件已存在，才更新为有效条目 - 因此
valid不宜设得过大（如超过 60s），尤其在用户可自主上传/覆盖静态资源的场景（如 CMS 图片管理） - 若业务要求“上传即可见”，建议
valid设为 10–30s，并确保open_file_cache_events已启用
如何让缓存策略匹配业务节奏？
不同更新频率的资源，应差异化设置参数：
-
构建产物类（如 dist/ 下 JS/CSS）：文件名带哈希（
app.a1b2c3.js），几乎不覆盖。可设inactive=300s、valid=120s，降低校验开销 -
用户上传类（如头像、商品图）：文件路径固定、内容常被覆盖。必须缩短
valid（≤20s），并开启events；min_uses可设为 1，避免首次访问就错过更新 -
高并发首页静态资源：访问密集但更新极少。适当提高
max（如 200000），延长inactive（120s），减少淘汰频次
