核心是用^~优先拦截静态路径以跳过重写逻辑；对/static/、/_next/等前缀配置^~ location，配合root/alias直接响应；后缀规则用~*统一处理并置于^~之后、/之前；主location用try_files替代if实现高效fallback。
关键在于让静态资源请求“不进重写逻辑”，而不是先匹配再排除。Nginx 的 location 匹配机制天然支持优先拦截静态路径，只要配置得当，就能跳过 rewrite、if、try_files 等耗时判断，直接由磁盘或缓存响应。
用 ^~ 精准拦截静态路径，终止后续匹配
这是最核心的手段。对已知静态前缀（如 /static/、/_next/、/assets/、/images/），必须使用 ^~ 修饰符：
- ^~ /static/ 一匹配就停止查找其他正则 location，不进 rewrite 或 if 块
- 对应 root 或 alias 配置后，Nginx 直接拼接文件系统路径返回，零逻辑开销
- Next.js 部署中务必加：location ^~ /_next/ { root /var/www/dist; }，避免被后面 / 拦截走
- 多个静态前缀按长度排序，/static/css/ 会比 /static/ 先命中（最长前缀原则）
把通用静态后缀规则放在重写逻辑之前
对 .js、.css、.png 等后缀，用 ~* 统一处理缓存和压缩，但位置很关键：
- 把它放在所有 ^~ 块之后、location / 之前
- 这样既不会干扰前缀拦截，又能确保所有未被 ^~ 拦住的静态请求（比如 /js/app.min.js）被快速捕获
- 示例：location ~* \.(js|css|png|jpg|gif|woff2)$ { expires 1y; add_header Cache-Control "public"; }
- 不建议拆成多个 ~ \.js$、~ \.css$，易遗漏且顺序敏感
在主 location 中主动跳过文件存在检查
很多 rewrite 依赖 if (!-e $request_filename) 实现前端路由 fallback，但这会为每个请求触发一次文件系统 stat 调用，开销明显：
- 若已用 ^~ 拦截了所有静态前缀，/static/、/_next/ 下的请求根本不会走到这里
- 剩下的 / 开头请求，绝大多数是 HTML 页面或动态路由，可直接用 try_files 替代 if + rewrite
- 推荐写法：location / { try_files $uri $uri/ /index.html; } —— 它内部优化了文件检查流程，比 if 更高效
- 尤其对 Next.js output: 'export' 模式，这条规则足够覆盖路由 fallback，无需额外 if
禁止对静态资源路径做 rewrite 或 return 干预
有些配置习惯性在 location / 里加 rewrite 或 return，容易误伤静态请求：
- 避免写：location / { if ($uri ~* \.(js|css)$) { rewrite ... } } —— 这种写法绕过了 ^~ 优势，还多一次正则匹配
- 不要在静态 location 内写 rewrite 或 return，除非有强业务需求（如强制跳转 CDN）
- 敏感路径如 /node_modules/、/src/ 可用 return 403 主动拦截，但不属于性能优化范畴
- Next.js 的 /favicon.ico 建议单独用 location = /favicon.ico 精确匹配，关闭日志刷屏
