在 macOS 上配置 Nginx 静态资源缓存需按文件类型分类设置 Expires 和 Cache-Control：JS/CSS/字体/图片等带哈希的资源设为 1 年缓存并启用 immutable；HTML 等动态资源禁用缓存；同时保持 ETag 默认开启以支持 304 协商缓存，并推荐使用哈希化 URL 规避更新问题。
在 macOS 上配置 Nginx 的静态资源缓存，核心是合理设置 Expires、Cache-Control 和 ETag 等响应头，让浏览器复用本地缓存，减少重复请求和带宽消耗。关键不在于“全开缓存”，而在于区分资源类型、控制更新节奏、避免缓存失效混乱。
明确静态资源范围并分类处理
Nginx 默认不会自动识别哪些是“静态资源”。需通过 location 块按文件后缀精准匹配，避免误缓存 HTML 或 API 接口：
-
长期缓存（1年）：JS、CSS、字体、图片等带哈希名的构建产物（如
main.a1b2c3.js） -
短期缓存（1小时）：未带哈希的资源（如
logo.png），或开发阶段频繁修改的文件 -
不缓存：HTML、PHP、API 路径（如
/api/）、带查询参数的资源（除非显式处理）
示例配置片段：
location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg|woff|woff2|ttf|eot)$ {
expires 1y;
add_header Cache-Control "public, immutable";
}
location ~* \.(html|htm)$ {
expires -1;
add_header Cache-Control "no-cache";
}启用 ETag 并配合 If-None-Match 验证
macOS 下 Nginx 默认开启 etag on，但需确保未被覆盖。ETag 是服务器生成的资源指纹，浏览器发起条件请求时携带 If-None-Match，Nginx 可直接返回 304 Not Modified，不传输响应体。
注意点：
- 若使用反向代理或 CDN，需确认上游是否透传或重写 ETag
- 对压缩后的资源（gzip/brotli），Nginx 会自动生成对应 ETag，无需额外配置
- 禁用 ETag 的场景极少（如负载均衡节点时间不同步导致 ETag 不一致），一般保持默认即可
利用版本化路径规避缓存更新问题
纯靠缓存时间无法解决“用户已缓存旧 JS，部署新版本后白屏”问题。最稳妥的方式是让资源 URL 随内容变化：
- 构建时生成带哈希的文件名（如 Webpack 的
[contenthash]） - HTML 中引用
/static/app.d7a9b3.js，而非/static/app.js - Nginx 无需特殊配置，因新 URL 视为全新资源，自然绕过旧缓存
若无法改文件名，可用查询参数（如 app.js?v=2.1.0），但需确保 Nginx 不忽略参数（默认不忽略），且注意 CDN 可能不缓存带参数的 URL。
验证与调试缓存行为
配置生效后，用 Chrome DevTools 的 Network 面板检查响应头：
- 查看
Cache-Control是否为public, max-age=31536000, immutable - 刷新页面时，静态资源状态码应为
200 (from memory cache)或304 - 修改文件后重新加载，确认新资源被拉取，旧缓存不再命中
命令行快速验证：
curl -I https://localhost/static/main.js
观察输出中 Cache-Control 和 ETag 字段是否符合预期。
