Nginx的location匹配严格按优先级执行：先=精确匹配（命中即停），再^~前缀匹配（最长且禁正则），然后按配置顺序执行~或~*正则匹配（首个命中即用），最后是普通前缀匹配（最长优先）。
nginx 的 location 匹配不看配置文件里谁写在前面，而是严格按四类语法的内在优先级执行。理解 =、^~、~（或 ~*）和普通前缀这四者的先后关系，是避免静态资源 404、API 路径错配、重定向混乱的关键。
= 精确匹配：最高优先级，命中即停
location = /api 只响应 完全等于 /api 的请求，不接受 /api/、/api/users 或 /api?x=1。一旦匹配成功，nginx 立即采用该块配置，跳过所有后续 location 判断——包括正则和更长前缀。它是最“霸道”的匹配方式，适合根路径、登录入口等确定性极强的 URI。
- 只允许完整字符串匹配，不支持通配或截断
- 不能带尾部斜杠（如 = /api/ 与 = /api 是两个不同规则）
- 常见用途：location = /、location = /favicon.ico、location = /healthz
^~ 前缀匹配：非正则、最长即止、禁止正则回溯
location ^~ /static/ 会匹配所有以 /static/ 开头的请求，比如 /static/css/app.css、/static/images/logo.png。关键在于：只要它成为当前 URI 的最长前缀匹配项，nginx 就直接采用它，不再检查任何 ~ 或 ~* 正则规则——哪怕后面有更“贴切”的正则也无效。
- 适用于静态资源目录，兼顾性能与可控性
- 注意：^~ 不是正则，不支持 . $ * 等元字符，纯字符串前缀比较
- 若同时存在 location ^~ /static/ 和 location /static/css/，后者因更长而优先生效（前提是没被 = 或更高优先级截断）
~ 和 ~* 正则匹配：顺序驱动，首个命中即用
location ~ \.(js|css|html)$ 和 location ~* \.png$ 属于正则匹配，它们不参与第一阶段的前缀比对，而是在前缀匹配完成后才被轮询。nginx 按照它们在配置文件中从上到下出现的顺序逐条尝试，一旦某条正则匹配成功，立刻终止后续正则检查，并应用该 location 块。
- ~ 区分大小写，~* 不区分；多数场景推荐 ~*
- 正则匹配只在“没有 = 或 ^~ 中断流程”时才生效
- 例如：/static/logo.PNG 会先被 location ^~ /static/ 截获，根本不会走到 ~* \.png$ 这一步
普通前缀匹配（无修饰符）：兜底但最弱，靠长度决胜
location /admin 和 location /admin/user 同时存在时，请求 /admin/user/settings 会命中后者，因为它是最长的普通前缀匹配。但它在整体优先级中排最后：即使它比某个 ~ 规则更长，只要 ~ 规则在前缀阶段未被触发，且正则阶段轮到它时能匹配，它就会胜出。
- 这是最常用也最容易误判的一类，比如 location / 和 location /api 都存在时，/api 请求一定走后者
- 它不“短路”，匹配后仍可能让位于后续的 = 或 ^~（如果 URI 恰好满足）
- 不要依赖书写顺序来控制这类 location 的行为，应靠路径设计本身体现层级
