Nginx静态资源优先匹配需严格遵循四层location匹配顺序：=、^~、正则、普通前缀；用^~锁定/static/等路径防反向代理截胡，慎用全局正则，合理使用root/alias及子路径隔离。
核心思路是让 Nginx 在匹配请求时，优先把静态资源交给正确的 location 处理，而不是被更宽泛的反向代理规则“截胡”。这依赖对四层匹配优先级的精准控制，而非堆砌规则。
明确四层匹配顺序，避免“默认兜底”误伤
Nginx 不是找“最像”的 location，而是按固定顺序逐级扫描，命中即停：
-
精确匹配（=）：如
location = /favicon.ico，只匹配该 URI，立即生效 -
优先前缀（^~）：如
location ^~ /assets/，匹配成功后不再检查任何正则规则 - 正则匹配（~ 或 ~*）：按配置文件中出现顺序，取第一个成功匹配项
-
普通前缀（无修饰符）：如
location /api/，取所有匹配中路径最长的那个
常见错误是把 location / 放在最前面，又没加 ^~ 或 = 限定，导致所有请求（包括 /static/logo.png）都先进入这个通用块，再 proxy_pass 到后端——而真正的静态文件根本没机会被 root 或 alias 服务。
用 ^~ 锁定静态资源路径，切断正则干扰
当静态资源集中在特定前缀下（如 /static/、/dist/），必须用 ^~ 明确声明其高优先级：
-
location ^~ /static/ { root /var/www/myapp; }—— 匹配/static/css/app.css时，直接读取文件，不进后续正则 - 即使后面还配了
location ~ \.js$ { ... }，也不会触发，避免缓存逻辑或权限规则误作用于该路径 - 注意
root和alias的路径拼接差异：root会拼完整 URI，alias会替换掉匹配部分
隔离子目录应用，防止跨目录资源加载错位
多个前端应用共存于不同子路径（如 /admin/、/user/）时，浏览器解析相对路径（./js/main.js）会自动去掉当前路径前缀，变成根路径请求，极易命中错误的 location：
- 访问
https://a.com/admin/，页面内引用js/app.js→ 浏览器实际请求/js/app.js - 若只有
location / { proxy_pass http://backend:5000; }，该请求就发给主服务，而非 admin 服务 - 解法一：为每个子应用单独定义带前缀的静态规则，如
location ^~ /admin/static/ { root /opt/admin/dist; } - 解法二：用
sub_filter动态重写 HTML 响应，把src="js/替换为src="/admin/js/，确保路径语义正确
谨慎使用正则，避免全局后缀匹配越界
像 location ~* \.(js|css|png)$ 这类通用正则看似方便，实则危险：
- 它会匹配
/api/v1/users.js、/legacy/report.css等本该走 proxy_pass 的接口路径 - 一旦放在
^~ /static/之后，就可能因顺序靠前而“抢走”本属于前缀块的请求 - 建议缩小作用范围：放在具体静态路径块内部嵌套，如
location ^~ /dist/ { ... location ~* \.js$ { expires 1h; } } - 或改用更安全的前缀 + 后缀组合：如
location ^~ /dist/js/ { expires 1h; }，避免正则泛化
