Nginx路径匹配遵循性能优先级逻辑：先精确匹配（=），再前缀优先（^~），后正则（~ / ~*），最后普通前缀与兜底（/）；不依赖配置顺序（除正则外），目标是用最少计算开销完成路由。
Nginx 的路径匹配不是“谁写在前面就用谁”，而是有一套明确、固定的性能优先级逻辑。核心原则是：**先快速筛选，再精细判断；能避免正则就绝不触发正则**。匹配过程不依赖配置顺序（除正则外），而是按类型优先级逐层决策，最终目标是用最少计算开销完成路由。
精确匹配（=）：最快响应，零开销
这是性能最优的匹配方式。Nginx 直接做字符串全等比较，不涉及任何通配或编译，毫秒级完成。一旦命中，立即终止匹配流程，后续所有 location 都不参与评估。
- 适用于固定路径，如 /health、/favicon.ico、/robots.txt
- 注意结尾斜杠：location = /api 不匹配 /api/ 或 /api/v1
- 不能含变量或正则语法，例如 location = /user/\d+ 无效
前缀优先匹配（^~）：静态路径的性能锚点
当请求以指定字符串开头时即命中，且关键特性是命中后跳过所有正则规则。这避免了正则引擎初始化、模式编译和逐字符扫描的开销，在高并发静态资源场景下显著降低 CPU 占用。
- 典型用途：/static/、/assets/、/dist/ 等前端资源目录
- 它比普通前缀（如 location /static/）优先级更高，也比所有 ~ 和 ~* 规则更早生效
- 即使某条正则规则更“精准”（比如 ~* \.js$），只要 ^~ 已匹配，就不会执行该正则
正则匹配（~ / ~*）：功能强但代价高
正则表达式需 Nginx 启动时预编译（PCRE 库），运行时逐条按配置顺序尝试匹配。每条正则都可能触发完整字符串扫描，频繁使用会明显拖慢吞吐量。
- ~ 区分大小写，~* 不区分大小写，后者内部需额外转换，略慢于前者
- 必须靠前书写高频规则（如 .css、.js），否则低频规则占位会导致关键路径多走几轮匹配
- 避免在正则中使用贪婪量词（如 .*）、嵌套括号或回溯-heavy 模式，易引发 ReDoS 风险
普通前缀与兜底（/）：安全但应尽量少用
无修饰符的 location /api 或 location / 属于最长前缀匹配，Nginx 需遍历所有前缀规则找出最长匹配项。虽然比正则快，但仍需多次字符串比对；而 location / 是最后防线，承担全部未覆盖请求，若它成为主力，说明其他规则设计不合理。
- location /api/v1/ 优先于 location /api/（更长前缀胜出）
- location /api/ 和 location /api 不同：前者不匹配 /api，后者匹配 /api 及 /api/、/api/foo
- 兜底规则建议仅做 try_files 或 proxy_pass，避免在其中嵌套复杂逻辑
