Nginx location匹配优先级取决于配置顺序而非精度：先按序扫描正则，首个成功匹配即生效，随后不再检查任何location（含更长前缀）；=和^~虽高优但若被上方正则截断则不生效；rewrite last会触发新URI的二次匹配。
前缀 location 和正则 location 的匹配优先级规则本身明确，但实际排查时容易忽略几个关键盲点：Nginx 并非“先看前缀再看正则”，而是先穷举所有前缀匹配（含最长前缀），再判断是否有更早定义的正则匹配成功。真正导致“高精度正则覆盖前缀”的，往往不是正则本身更“精确”，而是它在配置中位置靠前 + 能匹配请求路径，从而跳过后续所有前缀匹配逻辑。
盲点一：正则 location 出现在前缀 location 之前
Nginx 对正则 location 的扫描是按配置文件中出现的顺序进行的，一旦某个正则成功匹配，就立即使用它，不再检查后面的任何 location（包括更长的前缀）。这和“精度”无关，纯属顺序优先。
例如：
location ~ ^/api/ {
return 200 "from regex A";
}
location /api/v2/users {
return 200 "from prefix exact";
}
location /api/ {
return 200 "from prefix longest";
}
请求 /api/v2/users 会命中第一个正则（^/api/），返回 “from regex A”，而不是更精确的 /api/v2/users 前缀块。因为正则已提前匹配成功。
盲点二：前缀 location 使用了 = 或 ^~，但被上方正则截断
=（精确匹配）和 ^~（前缀匹配且不继续查正则）本应具有更高“实效优先级”，但前提是它们能被走到。如果上面有正则先匹配成功，这些高优前缀根本不会被评估。
常见误判：以为 ^~ /static/ 一定比 ~ \.js$ 优先 —— 实际上，如果 ~ \.js$ 写在 ^~ /static/ 上方，且请求是 /static/app.js，就会先进入正则分支，完全绕过 ^~ 块。
盲点三：URI 重写或内部跳转后触发二次 location 匹配
使用 rewrite ... last 或 return 301/302 后，新 URI 会重新进入 location 匹配流程，此时原始请求的“上下文”已丢失，完全按新 URI 和当前配置顺序重新匹配。容易误以为是原 location 块失效，其实是重写后进入了另一个正则分支。
排查建议：
- 用
nginx -T输出完整展开配置，确认所有 location 的文本顺序 - 开启
error_log /path/to/log debug;，并发送请求，搜索日志中"using configuration"行，它会明确告诉你最终选中的 location 及原因（如"regex" "location ~ ^/api/"或"prefix" "/api/v2/"） - 对关键路径，用
curl -v配合add_header X-Location-Hit $location;在各 location 块中临时打标，直观验证命中情况 - 避免把泛化正则（如
~ ^/api/）放在具体前缀（如/api/v2/users）上方；若必须，改用^~前缀替代，或把正则移到所有前缀之后
不复杂但容易忽略：匹配流程是线性的、顺序驱动的，不是树状择优。盯住配置顺序 + 开启 debug 日志，90% 的“优先级异常”都能快速定位。
