nginx location匹配顺序由修饰符类型和配置位置硬编码决定，不可手动调优；=精确匹配最高且立即终止，^~前缀匹配跳过后续正则，正则按书写顺序执行，普通前缀按最长+先定义优先，/兜底必须置末。
Nginx 的 location 匹配顺序不能手动“调整”优先级数值或开关控制，它由 Nginx 内部硬编码的匹配逻辑决定，完全依赖修饰符类型和配置书写位置。所谓“调顺序”，实质是通过合理选择修饰符、控制配置顺序、避免冲突规则来达成你想要的路由行为。
以下是关键操作点：
= 精确匹配永远最高，无法降级
location = /api只响应/api（不带查询参数、不带尾斜杠），且一旦匹配立即终止搜索。想让它不生效？删掉或改用其他修饰符。^~ 前缀匹配会跳过后续所有正则检查
如果你写location ^~ /static/ { ... }，那么即使后面有location ~ \.js$，对/static/app.js的请求也不会进入正则分支。这是强制“切断”正则流程的手段，适合静态资源目录。-
*正则匹配 (~ 和 ~) 按配置文件中出现的顺序执行，第一条命中即止**
想让某条正则优先？把它往上挪。比如：location ~* \.(svg|woff2?)$ { ... } # 先匹配字体/svg location ~* \.(jpg|png|gif)$ { ... } # 再匹配图片若反过来，
.jpg规则在前，.svg请求就会被错误捕获（除非扩展名不重叠）。 普通前缀匹配（无修饰符）按最长前缀 + 定义顺序决定
location /admin/和location /admin/users/同时存在时，/admin/users/list会命中后者（更长）；但若两者长度相同（如/api和/app），则谁写在前面谁生效。兜底规则
location / { ... }必须放在最后
它优先级最低，但会匹配一切未被前面规则捕获的请求。如果误放在中间，可能提前截断本该由正则或^~处理的路径。
真正要“调”的，不是优先级本身，而是：
- 用
=替代/path避免意外匹配； - 用
^~锁定高频静态路径，防止被正则干扰； - 把关键正则往前放，把宽泛正则往后放；
- 删除冗余或重叠的
location块，尤其是location /和location ^~ /并存时容易误判。
本质上，这不是排序题，而是路径建模题——看清每个请求 URI 实际走哪条路，再反推怎么写才不打架。
