优化静态文件缓存的关键是确保浏览器与Nginx两级缓存协同高效：精准路径匹配（如location ~*.(js|css|png|...)$）、可信响应头（Cache-Control public,immutable,max-age=31536000 + ETag）、open_file_cache减少I/O、预压缩（gzip_static/brotli_static）提升传输效率。
直接优化静态文件缓存应对突发流量，核心不是“多缓存”，而是让浏览器和 Nginx 两级缓存都稳、准、快地复用资源，减少对磁盘和后端的重复读取。关键在路径匹配精准、响应头可信、本地缓存高效、压缩与校验协同。
精准匹配静态资源路径
避免用泛泛的 location / 匹配所有请求，否则易误缓存动态内容或漏掉小众格式。应显式声明常见静态后缀，并统一处理规则：
- 用 location ~* \.(js|css|png|jpg|webp|gif|ico|woff2|ttf|svg)$ 精确捕获主流静态类型，大小写不敏感
- 把字体文件（woff2/ttf）单独再配一次，设更长有效期（如 expires 1y），因字体极少变更且体积大
- 排除带查询参数的请求（如 ?v=1.2.3），可用 if ($args != "") { add_header Cache-Control "no-cache"; break; } 防止版本参数污染缓存键
设置强效且可信的缓存响应头
仅靠 Nginx 的 expires 指令不够——客户端可能忽略它；需配合 Cache-Control 明确语义，并启用 ETag 提升命中率：
- expires 1y; 提供绝对过期时间，适合长期不变资源（如 logo.png、vendor.js）
- add_header Cache-Control "public, immutable, max-age=31536000"; ——immutable 告诉浏览器该资源永不变，无需再发条件请求；public 允许 CDN 和中间代理缓存
- add_header ETag $upstream_http_etag; 若上游返回了 ETag，透传给客户端；若无，则 Nginx 自动计算（需开启 etag on;）
启用 open_file_cache 减少磁盘开销
当并发猛增，大量请求集中读同一组静态文件时，反复 open/read/close 文件会拖慢 I/O。open_file_cache 把文件元信息（存在性、权限、inode、修改时间）缓存在内存中：
- open_file_cache max=10000 inactive=60s; 最多缓存 1 万个文件描述符，60 秒内未被访问则淘汰
- open_file_cache_valid 30s; 每 30 秒检查一次缓存项是否仍有效（比如文件是否被删或改）
- open_file_cache_min_uses 2; 同一文件至少被访问 2 次才纳入缓存，过滤偶然请求
- 搭配 open_file_cache_errors on;，连失败的 open（如文件不存在）也缓存，避免重复报错
配合 gzip_static 和 Brotli 提升传输效率
缓存的是文件内容，但传输仍可进一步压缩。优先使用预压缩（而非运行时压缩），降低 CPU 压力：
- 提前用 gzip 或 zopfli 生成 .gz 文件（如 app.js → app.js.gz），开启 gzip_static on;，Nginx 直接返回它，不走 runtime 压缩
- 如支持 Brotli（需编译时加 --with-http_brotli_module），配 brotli_static on;，Brotli 压缩率通常比 gzip 高 15%–20%
- 务必确认 gzip_vary on; 和 brotli_vary on; 已启用，使缓存系统（包括 CDN）能区分压缩/未压缩版本
