open_file_cache只缓存文件描述符（fd）和轻量元数据（如大小、mtime、存在性、权限、错误状态），不缓存文件内容，也不触发磁盘同步或干预文件系统缓存；必须配齐max、inactive、valid、min_uses、errors五项参数才生效。
open_file_cache 不做磁盘同步，它只缓存文件句柄（fd）和轻量元数据，不写磁盘、不触发 sync()、也不干预文件系统缓存行为。
它缓存什么，不缓存什么
缓存内容包括：
- 文件是否存在（open 成功/失败状态）
- 文件大小、修改时间、权限、是否为目录等 stat 结果
- 已打开的文件描述符（fd），供后续请求复用
- 错误状态，如 404、403 等（需 open_file_cache_errors on）
不缓存：
- 文件内容本身（内容由内核页缓存、sendfile 或 proxy_cache 负责）
- 任何需要 fsync 或 write 的磁盘写操作
- 文件系统级一致性状态（比如 ext4 journal 提交进度、NFS 缓存刷新时机）
它如何感知文件变更
有两种机制，互斥使用：
-
事件驱动（推荐）：启用
open_file_cache_events on后，Nginx 依赖 inotify 监听文件变化。一旦文件被修改、删除或重命名，内核立即通知 Nginx，它会标记对应缓存项为“过期”，下次访问时重新 open/stat -
轮询校验（兜底）：若未启用 events 或 inotify 不可用，则完全依赖
open_file_cache_valid定期扫描缓存项，调用 stat 检查文件状态。这个过程不触发磁盘写，只是读取元数据
注意：无论哪种方式，Nginx 都不会主动调用 sync()、fsync() 或 fdatasync() —— 它不负责保证你写的文件已落盘。
与内核页缓存的关系
open_file_cache 和内核页缓存（page cache）是两层独立机制：
- 前者在用户态管理 fd 和元数据，减少系统调用次数
- 后者在内核态缓存文件内容块，影响 read()/sendfile() 效率
- 两者协同工作：open_file_cache 复用 fd → sendfile 直接从 page cache DMA 发送 → 零拷贝完成响应
也就是说，即使 open_file_cache 命中，实际发送内容仍依赖内核是否已把文件加载进内存；若未命中 page cache，仍会触发一次磁盘读（但跳过了 open/stat）。
配置生效的关键约束
以下设置直接影响缓存能否真正复用 fd：
-
worker_rlimit_nofile必须足够大（建议 ≥65535），否则缓存了 fd 也打不开新文件 -
open_file_cache必须配齐max、inactive、valid、min_uses、errors五项，缺一不可 - 若大量文件变更频繁，需检查
/proc/sys/fs/inotify/max_user_watches是否够用，否则 inotify 事件丢失导致缓存滞后
它不解决“文件刚写完就立刻被 Nginx 访问却读到旧内容”的问题——那属于应用层写入顺序或 fsync 控制范畴，open_file_cache 仅确保“知道文件现在是什么状态”。
