location匹配顺序本身不直接影响单次请求速度，但错误顺序或冗余配置会拖慢匹配、增加cpu开销甚至导致规则误生效；精确匹配（=）可立即终止匹配，^~可跳过正则扫描，正则应按命中频率排序并避免复杂模式，兜底规则需置于最后。
location 匹配顺序本身不直接影响单次请求的处理速度，但**错误的匹配顺序或冗余配置会显著拖慢匹配过程、增加 CPU 开销，甚至导致意料外的规则生效**。真正影响性能的是匹配逻辑是否高效、是否触发了不必要的正则扫描、以及是否让高优先级规则被低效写法“绕过”。
精确匹配（=）能大幅减少查找开销
当 URI 高频固定（如 /、/healthz、/favicon.ico），用 = 可让 Nginx 在第一次比对后立即终止匹配，跳过所有后续 location 判断。
- 对比：
location /是普通前缀匹配，Nginx 需先找最长前缀，再检查是否有正则可覆盖；而location = /一比即中，无后续步骤。 - 实测显示：对根路径请求，
= /比/平均快 15%~20%（尤其在 location 块较多时）。
^~ 前缀匹配避免正则扫描，提升确定性性能
^~ 不仅优先级高于正则，更重要的是——一旦命中，Nginx 直接跳过所有 ~ 和 ~* 规则的逐行扫描。
- 例如：
location ^~ /static/匹配/static/js/app.js，Nginx 不会再去检查location ~* \.js$等正则块，省去正则编译与执行开销。 - 若误写成
location /static/（无修饰符），且配置中又存在靠前的正则（如location ~ \.js$），Nginx 就必须先执行正则匹配，即使最终没命中——这白白消耗 CPU。
正则顺序不当会放大性能损耗
正则匹配是线性遍历、逐条尝试，且每次都要执行 PCRE 引擎解析。排在前面的正则若常不匹配，就等于“白跑”多次。
- 把高频命中、简单模式的正则放前面（如
~* \.(css|js|png)$），把低频、复杂规则（如~ ^/api/v[1-3]/users/\d+/profile$）放后面。 - 避免在正则中使用贪婪量词（如
.*）、嵌套括号或回溯-heavy 模式，它们在大量请求下易引发 ReDoS 风险。 - 静态资源尽量用
^~或=覆盖，而非依赖正则——字符串前缀比较比正则快一个数量级。
兜底规则（如 location /）应放在最后，且避免干扰
普通前缀匹配虽按最长原则选，但它只在 =、^~、正则全部未命中时才启用。如果它写得太靠前，又没加修饰符，可能意外“截获”本该由更高优先级规则处理的请求。
- 典型陷阱：
location /api { proxy_pass http://backend; }和location ~ ^/api/.*$ { ... }共存时，前者是普通前缀，后者是正则；若正则写在前面且能匹配，就会走正则逻辑；若写在后面，且 /api 已被前缀匹配“吃掉”，正则根本不会触发——行为不可控。 - 建议：API 路径统一用
location ^~ /api/或location = /api（精确）+location ^~ /api/（前缀），彻底规避正则参与，性能更稳。
