Nginx location匹配虽不依赖执行顺序，但线性扫描导致规则越多性能越差；应精简合并同类项、优先用精确匹配=、慎用正则、避免嵌套、改用map提前分流。
Nginx 的 location 匹配本身不依赖顺序执行，但匹配过程是线性扫描的：它会逐条比对请求路径与所有 location 规则，直到找到最精确匹配（前缀匹配）或第一个正则匹配（按配置顺序）。所以 location 块越多、越杂乱，初始匹配耗时越长——尤其在高并发下，每毫秒延迟都可能放大成可观的性能损耗。
精简 location 块不是删功能，而是合并同类项、避免冗余、提前收口。
合并语义相同或路径相邻的 location
多个只做静态文件服务、日志关闭或简单重定向的 location，往往可以归并：
- ❌ 不推荐（重复逻辑、分散维护）：
location /favicon.ico { log_not_found off; access_log off; } location /robots.txt { log_not_found off; access_log off; } location /apple-touch-icon.png { log_not_found off; access_log off; } - ✅ 推荐（用正则一次覆盖，且仅限安全静态资源）：
location ~* \.(ico|png|gif|jpg|jpeg|webp|txt|xml|svg)$ { log_not_found off; access_log off; expires 7d; add_header Cache-Control "public, immutable"; }注意：正则 location 比前缀 location 代价高，所以只用于真正需要通配的场景；上面示例中
.txt和.xml若仅用于/robots.txt/sitemap.xml等固定路径，更优解是用精确匹配location = /robots.txt。
用 = 精确匹配替代前缀匹配
对已知固定路径（如 /healthz、/ping），优先使用 location = /path：
- 它不参与前缀树比较，Nginx 会直接哈希查找，速度最快；
- 不会触发任何继承或 fallback 行为，语义明确。
location = /healthz { return 200 "OK"; add_header Content-Type text/plain; } location = /ping { return 204; }
避免嵌套 location + 多层 rewrite
深层嵌套（如 location /api { location /v1 { ... } }）不仅难读，还增加解析深度和匹配跳转次数。更合理的方式是：
- 把版本路由交给上游（如后端网关）或用
map提前提取变量； - 或统一用单层
location ~ ^/api/v[12]/+proxy_pass转发，减少 Nginx 内部路径重写。
用 map 提前分流，减少 location 数量
当存在大量基于路径前缀的条件行为（比如按路径分发到不同 upstream），不要写几十个 location /shop/, location /blog/, location /admin/……
改用 map 在 http 块中一次性映射：
map $request_uri $upstream_backend {
~^/api/shop/ shop_backend;
~^/api/blog/ blog_backend;
~^/api/admin/ admin_backend;
default default_backend;
}
server {
location /api/ {
proxy_pass http://$upstream_backend;
}
}这样只需一个 location，匹配开销降到最低，逻辑也更集中可维护。
不复杂但容易忽略
