Nginx路径匹配按优先级逐层筛选且仅选一个location执行：先精确匹配（=），再^~前缀（最长且跳过正则），然后普通前缀（最长或先出现），再正则（从上到下首个匹配），最后兜底/。
Nginx 路径匹配不是“谁写在前面就用谁”，而是按明确优先级逐层筛选，最终只选一个 location 块执行。理解这个决策过程，是避免 proxy_pass 错转、静态资源404或正则被跳过的前提。
精确匹配（=）：一锤定音
只要请求 URI 和 location = /xxx 后的字符串完全一致（包括大小写、结尾斜杠、无多余路径），就立即命中，不再检查其他规则。
- 例如：
location = /login只匹配/login，不匹配/login/、/login?a=1或/login-page - 它优先级最高，匹配成功后整个匹配流程终止
前缀匹配分两类：^~ 有特权，普通前缀看长度
location ^~ /static/ 和 location /api 都属于前缀匹配，但行为不同：
-
^~表示“最长前缀匹配胜出后，直接使用，跳过所有正则检查”——适合静态资源目录，确保安全不被后续正则干扰 - 普通前缀（无修饰符）按“最长字符串匹配”原则选择：对请求
/api/v2/users，location /api/v2/比location /api/更长，因此优先 - 若长度相同（如
/a和/a并存），则取配置文件中先出现的那个
正则匹配（~ 和 ~*）：顺序决定命运
正则规则不比长度，只比书写顺序——Nginx 从上到下扫描，遇到第一个能匹配的就停，不会继续找“更优”的正则。
-
~区分大小写，~*不区分；例如~ \.JS$不匹配/script.js，而~* \.js$可以 - 常见陷阱：把宽泛正则（如
~ .*）写在前面，会吞掉本该交给^~ /assets/处理的请求 - 它只在“没有 = 匹配、也没有 ^~ 匹配”时才参与竞争
兜底规则（location /）：永远在最后候场
location / 是默认 fallback，只有当所有其他规则都未命中时才会生效。它本质是“最短前缀匹配”，因为 / 是所有合法 URI 的前缀。
- 不要把它放在最前面——否则会提前截断，导致后面更具体的规则失效
- 常用于反向代理主入口：
proxy_pass http://backend;，但需确保它不被更早的=或^~意外覆盖 - 若想让某些路径“逃出”兜底逻辑，必须显式定义更高优先级的 location
