Nginx location匹配分两步：先选最长前缀（^~优先于普通前缀），若为普通前缀则按配置顺序依次尝试正则匹配，命中即止；正则间不比精确度，只按书写顺序执行。
Nginx 的 location 正则匹配不是按书写顺序执行的，而是遵循“最长、最精确的正则匹配优先”规则——但仅限于正则表达式（~ 和 ~*）之间比较；它不会和前缀匹配（location /abc）直接比优先级，而是先走前缀匹配逻辑，再在需要时才进入正则扫描。
正则 location 的匹配顺序：不看书写顺序，只看“谁更具体”
所有以 ~（区分大小写）或 ~*（不区分大小写）开头的 location 都属于正则匹配块。Nginx 会收集所有正则 location，**按配置文件中出现的先后顺序逐个尝试匹配**——但前提是：该请求未被更优的前缀 location 完全覆盖。
- 只要有一个正则匹配成功，Nginx 就立即停止后续正则检查，不会继续往后找
- 所以，把更具体的正则写在前面，能提高效率并避免误匹配（比如
~* \.php$应放在~* \.(js|css|png)$后面？错——如果希望 PHP 优先，就把它写在前面） - 注意：
^~前缀匹配一旦命中，会跳过所有正则检查，无论正则多精准
前缀匹配 vs 正则匹配：两套机制，分阶段执行
Nginx 匹配 location 分两步：
-
第一步：找最优前缀匹配 —— 比较所有普通前缀（如
/、/api、/static/）和^~前缀，选出最长的那一个 -
第二步：决定是否进正则 —— 如果最优前缀是
^~，直接用它，跳过正则；如果是普通前缀（没加^~），则继续遍历所有~/~*location，按配置顺序找第一个匹配的
例如：location /api/（普通前缀） + location ~ ^/api/user/\d+$，当访问 /api/user/123 时，虽然 /api/ 是最长前缀，但它只是普通前缀，Nginx 还会继续检查正则，并可能命中后者。
实用建议：怎么写才不容易出错
- 明确意图：想让某规则“绝对优先”，用
^~前缀（如location ^~ /static/） - 正则尽量加锚点：用
^/xxx或\.ext$减少误匹配（比如~ \.php$比~ php安全得多） - 大小写敏感慎用：
~*更常用，除非业务明确要求区分（如某些 API 路径） - 调试技巧：开启
error_log /path/to/log notice;，访问时看日志里实际选中的 location 块
一个小例子看懂执行流
假设有以下配置：
location /img/ {
return 200 "prefix /img/";
}
location ^~ /img/icons/ {
return 200 "prefix ^~ /img/icons/";
}
location ~* \.(jpg|jpeg|gif|png)$ {
return 200 "regex image";
}
location ~ ^/img/admin/ {
return 200 "regex admin";
}访问 /img/admin/logo.png：
- 前缀匹配阶段：最长的是
/img/和/img/icons/，但/img/icons/不匹配路径，所以选/img/ - 因为
/img/是普通前缀（非^~），进入正则扫描 - 按顺序检查：
\.(jpg|...)匹配成功 → 返回 “regex image”，后面的^/img/admin/根本不执行
如果把 ~ ^/img/admin/ 写在前面，就能先匹配到它。
