nginx location匹配优先级从高到低为：=精确匹配→^~最长前缀匹配→~和~*正则按配置顺序→普通前缀匹配；不同前缀类型影响匹配逻辑与生效结果，需依规则合理配置。
Nginx 的 location 指令用于定义如何处理不同 URL 路径的请求，它的匹配逻辑不是“写在前面就先执行”，而是有一套明确的优先级规则。理解清楚匹配顺序和写法，才能避免配置失效或路由错乱。
location 匹配类型与语法格式
Nginx 支持多种 location 前缀，不同前缀影响匹配方式和优先级：
-
普通前缀（无修饰符）：如
location /api { ... }，表示前缀匹配，最长匹配成功即停止（但可能被更高优先级覆盖） -
= 精确匹配：如
location = /login { ... }，只匹配完全一致的 URI，优先级最高 -
^~ 非正则前缀匹配：如
location ^~ /static/ { ... }，匹配最长前缀且不进行正则检查，优先级高于普通前缀但低于精确匹配 -
~ 正则匹配（区分大小写）：如
location ~ \.(jpg|png|gif)$ { ... } -
~* 正则匹配（不区分大小写）：如
location ~* \.js$ { ... } -
@ 命名 location（仅内部跳转用）：如
location @fallback { ... }，不参与常规请求匹配
匹配优先级顺序（从高到低）
当一个请求进来时，Nginx 按以下固定顺序查找 location：
- 先找 = 精确匹配，命中即停止，不继续匹配
- 再找 ^~ 最长前缀匹配，一旦找到最长匹配项，也立即停止，不检查正则
- 最后扫描所有 ~ 和 ~* 正则表达式，按配置文件中出现的**顺序**逐个尝试，第一个匹配成功的即生效
- 如果以上都未命中，则使用最长普通前缀（无修饰符）匹配
注意：^~ 和普通前缀都属于“前缀匹配”，但 ^~ 具有“短路”效果——只要它匹配上，就不会再看后面的正则；而普通前缀只是兜底，优先级最低。
常见易错点与实用建议
实际配置中容易踩坑的地方：
- 不要混用
^~和正则去匹配同一类路径，比如location ^~ /img/和location ~ \.png$同时存在时，/img/logo.png会直接走^~分支，根本不会进正则 - 正则 location 的顺序很重要，
~ \.html$写在~ \.htm$前面，那/a.htm就不会匹配到后者 - 路径结尾的
/很关键：location /admin会匹配/admin、/admin/、/admin/foo；而location /admin/更推荐，语义更清晰且避免歧义 - 想让某个路径强制走正则？加
^~就不行，得确保它没被更高优先级的前缀挡住，必要时用=或调整位置
一个典型配置示例
下面是一个兼顾静态资源、API 和兜底的常用结构：
location = /favicon.ico { log_not_found off; access_log off; }
location = /robots.txt { log_not_found off; access_log off; }
<p>location ^~ /static/ {
root /var/www/app;
expires 1y;
}</p><p>location ~* .(js|css|png|jpg|jpeg|gif|ico|svg)$ {
root /var/www/app;
expires 1y;
}</p><p>location /api/ {
proxy_pass <a href="https://www.php.cn/link/65b5b8d1f89bf53a5713bc3afdd83e9e">https://www.php.cn/link/65b5b8d1f89bf53a5713bc3afdd83e9e</a>;
proxy_set_header Host $host;
}</p><p>location / {
try_files $uri $uri/ /index.html;
}</p>
这个顺序保证了：图标和机器人文件最快响应；静态目录走高效前缀匹配；其余静态后缀由正则兜底；API 请求独立转发；最后所有其他请求交给前端路由处理。
