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 时，严格按以下顺序判断：
- 先找
=精确匹配，命中即停 - 再找所有普通前缀匹配（含
^~），记录最长前缀匹配项 - 若最长前缀匹配项带
^~，直接采用它，跳过正则匹配 - 否则，用上一步记录的最长前缀长度为基准，遍历所有正则 location，按顺序找第一个匹配项
- 如果没有任何正则匹配，则使用第 2 步记录的最长前缀匹配项
常见陷阱与建议
实际配置中容易踩坑，注意这些细节：
- URI 匹配的是解码后的路径（如
%20已转为空格），但正则中写的是原始字符，不要对编码字符写正则 -
location /a会匹配/abc和/a?x=1，但不会匹配/A（普通匹配不区分大小写？错！Nginx 普通 location 是区分大小写的，除非用~*） - 避免滥用正则：高频请求路径（如 API 前缀）优先用
^~或普通前缀，提升性能 - 调试时可用
nginx -t验证语法，配合error_log debug查看实际匹配的 location（需编译时启用 debug 日志）
