nginx静态资源缓存需按类型精准配置：用~*正则匹配后缀（如js/css设expires 1y+immutable，图片设30d），或用^~前缀匹配/static/目录提升性能；严禁在location /、.html或顶层块中全局设置expires；响应头需手动补全cache-control语义，并用nginx -t和curl校验。
关键在于按资源类型精准匹配、避免泛化规则，同时确保 expires 和 Cache-Control 协同生效，不干扰动态内容。
用 ~* 正则匹配静态后缀，覆盖主流资源
这是最常用也最可控的方式，不区分大小写，明确限定缓存范围：
-
location ~* \.(js|css|woff2?|ttf|eot|svg|webp)$：适合字体、样式、脚本等带哈希的长期资源，设expires 1y并加immutable -
location ~* \.(jpg|jpeg|png|gif|ico|bmp|avif|jxl)$：图片类资源更新较频繁，建议expires 30d，不加immutable - 正则末尾必须加
$，防止误匹配路径中含类似后缀的动态 URL（如/api/user.png?id=1）
用 ^~ 匹配静态目录，性能更高更安全
当所有静态资源统一放在 /static/ 或 /assets/ 下时，优先选前缀匹配：
location ^~ /static/ { expires 1y; add_header Cache-Control "public, immutable"; }-
^~比正则优先级高，且不回溯，无性能损耗，也不受后续正则干扰 - 确保该路径下只放真正不变的资源；若混入需频繁更新的文件，缓存策略要相应缩短
绝对避开危险配置位置
以下写法看似省事，实则极易导致 HTML 页面、API 响应被错误缓存：
- 不要在
location /中写expires—— 所有请求都会命中，包括登录页、接口返回 - 不要用
location ~ \.html$设置长缓存 —— 静态生成的 HTML 若没加哈希，更新后用户刷不出来 - 不要把
expires放在server或http块顶层 —— 缺乏上下文，无法精准控制
补全并校验响应头
expires 指令会自动设置 Expires 和基础 Cache-Control: max-age=xxx，但需手动补全语义：
- 带哈希资源：加
add_header Cache-Control "public, immutable"，让浏览器跳过协商缓存 - 图片、未哈希资源：用
"public, max-age=2592000"（30 天），不加immutable - HTML/PHP/JSON：设
expires epoch或expires -1，再加"no-cache, must-revalidate, max-age=0" - 改完配置务必执行
nginx -t验证，再用curl -I https://yoursite.com/test.js检查响应头是否符合预期
