这是一篇关于Nginx中Location规则的补充说明。重点在于测试路径规则和^~规则以及正则规则同时匹配的情况，可以参考我的上一篇文章。
网络上有些文章总结了下列优先级顺序
首先精确匹配 =
其次前缀匹配 ^~
其次是按文件中顺序的正则匹配
然后匹配不带任何修饰的前缀匹配。
最后是交给 / 通用匹配
当有匹配成功时候，停止匹配，按当前匹配规则处理请求
针对这个说法，有些不妥之处。
示例，有如下规则配置，在配置中使用return直接返回内容，仅仅用于说明问题
server {
listen 80;
server_name localhost;
location ^~ /a/b/ {
# 规则1
return 200 "^~ location";
}
location /a/b/c/ {
# 规则2
return 200 "path location";
}
location ~* \.(txt) {
# 规则3
return 200 "regex text";
}
}
当有如上配置规则时，
当我们访问 /a/b/c/xxx.txt 时，以上三条规则均可满足条件。那么返回的信息是什么呢？如果按照如前所述的规则匹配优先级，^~ /a/b/ 的优先级似乎最高，但事实上的结果呢。返回的是
regex text
没错，响应的文本是 "regex text"，而不是意料中的"^~ location"。但这个现象能说明正则表达式的优先级高于path吗？
我们使用 /a/b/xxx.txt 访问时 ，得到的结果却是 "^~ location",规则1的优先级高于规则3.
结果是不是很懵？
再次强调nginx的路径匹配过程 参考我的上一篇文章//www.greatytc.com/p/20b67ae85b51
一、检查请求uri是否与某个=规则匹配，如果有，直接应用规则，终止后续匹配。
二、nginx首先检查所有路径匹配规则配置项，包括"^~"规则和没有前导符号的规则，选择并记住和当前请求uri匹配度最长的配置项。但这个时候，并不会启用相关的配置，而仅仅是记住。
三、判断上一步中选择下来的路径规则是否包含 ^~ ，如果包含，则使用该条规则，终止后续匹配。
四、按配置顺序进行正则表达式检查，匹配到第一条合适的正则表达式时，使用该条规则，终止后续匹配。
五、使用步骤三选择出来的路径匹配规则。
总结：
- 路径匹配规则一定会执行，并且会将匹配到的规则记录下来待用。然后判断路径匹配规则是否 ^~ 开头，如果是，直接应用规则，如果不是，进行正则匹配，并应用匹配到的正则规则。
- 路径匹配规则的优先级和顺序无关，和匹配度相关。
