Nginx location匹配严格按优先级顺序：先=精确匹配，再找最长普通前缀匹配，若含^~则终止并采用，否则遍历正则匹配；普通匹配区分大小写，URI已解码，正则需注意编码与性能。

Nginx 的 location 指令用于匹配请求 URI，但不同写法的匹配行为差异很大，尤其在路径前缀匹配（普通 location）和正则匹配（~、~*）之间，优先级、匹配逻辑和适用场景都不同——搞错容易导致配置不生效或路由错误。

普通前缀匹配（无修饰符或 =、^~）

这类匹配基于 URI 的字符串前缀，不涉及正则引擎，性能高，且有明确的优先级规则：

• location /api/：匹配所有以 /api/ 开头的 URI，如 /api/users、/api/v1/products?x=1（查询参数不影响匹配）
• location = /：精确匹配根路径，仅匹配 /，不匹配 /index.html 或 //
• location ^~ /static/：前缀匹配，且一旦命中就立即停止搜索正则 location，适合静态资源等需快速终止匹配的场景

正则匹配（~ 区分大小写，~* 不区分大小写）

正则匹配在普通前缀匹配之后执行（除非被 ^~ 中断），支持复杂模式，但性能略低，且全部按配置顺序逐条尝试：

• location ~ \.php$：匹配以 .php 结尾的 URI，如 /index.php、/admin/test.PHP（~ 区分大小写，所以后者不匹配）
• location ~* \.(js|css|png|jpg)$：不区分大小写，匹配常见静态文件后缀
• 多个正则 location 按配置文件中出现的先后顺序匹配，第一个成功即用，后续不再检查

匹配优先级是关键，不是“谁写在前面谁生效”

Nginx 决定使用哪个 location 时，严格按以下顺序判断：

1. 先找 = 精确匹配，命中即停
2. 再找所有普通前缀匹配（含 ^~），记录最长前缀匹配项
3. 若最长前缀匹配项带 ^~，直接采用它，跳过正则匹配
4. 否则，用上一步记录的最长前缀长度为基准，遍历所有正则 location，按顺序找第一个匹配项
5. 如果没有任何正则匹配，则使用第 2 步记录的最长前缀匹配项

常见陷阱与建议

实际配置中容易踩坑，注意这些细节：

• URI 匹配的是解码后的路径（如 %20 已转为空格），但正则中写的是原始字符，不要对编码字符写正则
• location /a 会匹配 /abc 和 /a?x=1，但不会匹配 /A（普通匹配不区分大小写？错！Nginx 普通 location 是区分大小写的，除非用 ~*）
• 避免滥用正则：高频请求路径（如 API 前缀）优先用 ^~ 或普通前缀，提升性能
• 调试时可用 nginx -t 验证语法，配合 error_log debug 查看实际匹配的 location（需编译时启用 debug 日志）