open_file_cache 能显著降低 SPA 响应延迟，关键在于精准缓存 index.html（inactive=20s、min_uses=2）和哈希静态资源（inactive=300s、valid=60s），并启用 open_file_cache_errors 防止恶意 404 扫描拖垮 I/O。
要让 open_file_cache 真正缩短单页应用（如 React、Vue）的响应时间，核心不是“开了就行”，而是围绕 index.html 和哈希静态资源的访问特征，精准配置缓存行为——它不加速内容传输，但能砍掉每次请求里反复 stat()、open() 带来的毫秒级延迟，尤其在高并发或磁盘较慢时效果立现。
聚焦 SPA 的关键路径：index.html 是缓存重点
单页应用每次刷新、直接访问根路径、或服务端 fallback（如 try_files $uri $uri/ /index.html），都会触发对 index.html 的读取。这个文件体积小、更新频次低、但访问极密。open_file_cache 对它的优化收益最高：
- 设 inactive=20s：匹配用户操作节奏，20 秒内重复访问（如快速刷新、路由回退）可复用缓存条目
- 保持 min_uses=2：避免探针或爬虫单次请求污染缓存
- 搭配 try_files $uri $uri/ /index.html; 时，单次请求最多触发 3 次文件检查，缓存后这 3 次 stat/open 全部省去
哈希资源也要进缓存，但策略不同
app.abc123.js、style.def456.css 这类带内容哈希的文件，URL 不变即内容不变，访问也密集。它们适合更宽松的缓存策略：
- 可适当提高 max=3000–5000，容纳更多稳定资源条目
- inactive=300s（5 分钟） 更合理：这类文件上线后极少变更，延长驻留时间提升复用率
- valid=60s 足够：校验间隔拉长，减少主动 stat 开销，又不至于错过人工紧急回滚
必须打开错误缓存，防恶意扫描拖垮 I/O
SPA 常有前端路由（如 /user/profile），Nginx fallback 到 index.html 前会先查 /user/profile 是否存在。攻击者或错误配置可能高频请求 /wp-admin/.htaccess、/.git/config 等不存在路径：
- open_file_cache_errors on; 必须启用——把 “404” 结果也记进内存，后续相同路径请求直接返回，不再碰磁盘
- 否则，单个恶意 IP 扫描 1000 个不存在路径，就会引发 1000 次 stat()，I/O 瞬间打满
验证是否真起效，看三项指标
配完不能只信 reload 成功，要观察运行态：
- 用 lsof -p $(cat /var/run/nginx.pid) | wc -l 对比开启前后稳定流量下的句柄数，下降 20%+ 是明显信号
- 通过 nginx_stub_status 查
ngx_http_open_file_cache_hits与misses比值，理想情况应 > 4:1 - 对同一 CSS 文件连续发两次请求，用 strace -e trace=open,stat -p $(cat /var/run/nginx.pid) 观察系统调用是否从 2 次 open+2 次 stat 缩减为 0 次
