为什么开了 `open_file_cache` 图片会不显示？

结论：这三行配置和你的静态文件服务场景冲突了，直接注释掉是正确的选择。

根本原因：inactive=20s太短了

你的配置：

open_file_cache max=100000 inactive=20s; open_file_cache_valid 30s; open_file_cache_min_uses 2;

逐参数拆解：

具体 failure 场景

时间线： 0s 用户A访问 /static/avatar.jpg → nginx打开文件，加入缓存 15s 用户B访问同一张图 → 还在缓存里，直接返回 ✅ 21s 没人访问了 → inactive超时，缓存删除 ❌ 25s 用户C访问同一张图 → nginx重新打开文件 ↓ 此时如果： ① Django 的 collectstatic 正在运行（覆盖了文件） ② 某个上传操作正在写入这个文件 ③ Windows 文件锁定（你是 Windows 环境！） → nginx 打开文件失败 → 返回 404/500 → 图片不显示 ❌

你的环境是 Windows（E:/Python/...），文件锁定比 Linux 严重得多，这个问题会更频繁。

为什么min_uses=2也有问题？

一张图片只被访问过1次 → 不进缓存 → 每次都要重新打开文件 → 更容易碰到文件锁定 → 更容易不显示。

正确做法

方案一：直接注释掉（推荐）

# open_file_cache max=100000 inactive=20s; # open_file_cache_valid 30s; # open_file_cache_min_uses 2;

理由：你的静态文件就在本地磁盘（alias E:/...），nginx 读取本地文件的开销极小，open_file_cache带来的收益几乎为零，但引入了缓存一致性风险。不值得。

open_file_cache真正有用的场景是：

• 跨网络读取文件（NFS、SMB 共享）
• 超高并发下同一个文件被成千上万次访问

你的场景是本地磁盘 + Django 静态文件，不属于这两种。

方案二：如果一定要用，调参

open_file_cache max=10000 inactive=5m; # 5分钟没人访问才删除 open_file_cache_valid 2m; # 缓存信息2分钟内有效 open_file_cache_min_uses 1; # 访问1次就进缓存

但说实话，还是没必要。

你的配置里真正该关注的点

你这份 nginx 配置整体写得不错，但有几个地方值得注意：

一句话总结

open_file_cache是给 NFS/高并发场景用的，本地静态文件服务开它属于引入了风险但没拿到收益。注释掉，问题消失。