项目背景
前端Vue项目，同时支撑PC网站、手机M站和手机App，在项目构建之后会有三个子目录作为路由分别对应m站、PC和APP，但是该项目作为一个服务对外提供服务需要一个统一的请求入口，比如
location /xx {
root /data/website;
}
而不是在每个域名下各自己配置不同的入口，比如
# pc 域名下配置
location /xx/pc {
root /data/website/pc;
}
# m站域名下配置
location /xx/m {
root /data/website/pc;
}
# app域名下配置
location /xx/app {
root /data/website/pc;
}
这样的配置虽然从实现是没有问题的，但是从运维维护成本上来说很大，如果它以后要支撑不同的渠道，那就是在N多配置文件中添加N多类似的配置
当前项目的目录结构如下
|-- website
|---- pm-live-m
|------ index.html
|---- pm-live-pc
|------ index.html
|---- pm-live-app
|------ index.html
|---- a.js
|---- b.css
遇到问题
因为是前端资源，还涉及到静态资源问题，前端项目为了统一标准，一般都会有个识别的前缀，比如，不管是从PC还是APP过来的请求，/view/ 都是请求到对应的前端资源的。所以刚开始的配置
location /view/ {
alias /data/website/;
}
那么如下请求是没有问题的
curl 'https://www.colinspace-demo.com/view/pm-live-m/'
curl 'https://www.colinspace-demo.com/view/pm-live-pc/'
curl 'https://www.colinspace-demo.com/view/pm-live-app/'
但是如果请求上带上参数的，一般都是通过 ?param=xxx 的方式，但是开发说，这样的请求不优雅，好吧，那就实现优雅的方式，其实就是URL的伪静态实现 有时候叫 History模式
参考：
所有上面的配置变为
location ~ /view/(.*)/ {
alias /data/website/;
try_files $uri $uri/ /$1/index.html;
}
但是结果却未出人意外，请求404报错，提示文件不存在，但是文件自己确认是存在，那就是配置的问题。
最终分析和查阅资料才发现是try_files的问题，
知识点1： Nginx的 alias 和try_files 两个之间存在互斥，不能同时配置。
问题分析解决
1、既然不能共存，但是要实现优雅的URL，请求不存在的时候转发到指定的HTML页面，但是try_files是必须的
2、既然try_files得用，除了alias之外，就只能用 root了
至于alias和root的区别，简单来说：
- root 指令只是将搜索的根设置为 root 设定的目录，即不会截断 uri，而是使用原始 uri 跳转该目录下查找文件
- alias 指令则会截断匹配的 uri，然后使用 alias 设定的路径加上剩余的 uri 作为子路径进行查找，支持正则表达式
附加知识点： Nginx中root和alias导致的URI的截取
3、但是如果使用 root，根据其作用，知道 location就不能使用view了，同时前端规范静态资源请求还是需要view的，那么view的配置还是需要保留，然后做静态资源请求
4、既然view保留做静态资源，那么路由就需要另外的路由入口，和开发协商，项目产生物结构变更为如下：
|-- website
|---- pm-live
|------ pm-live-m
|-------- index.html
|------ pm-live-pc
|-------- index.html
|------ pm-live-app
|-------- index.html
|---- a.js
|---- b.css
pm-live作为入口路由，Nginx的配置如下
location ~ /pm-live/(.*)/ {
root /data/website/;
try_files $uri $uri/ /$1/index.html;
}
又遇到问题 rewrite or internal redirection cycle while internally redirecting to， 根据报错提示出现循环重定向，为啥会这样呢
原因在于try_files 会按照顺序就检索对应的Uri是否存在，不存在就查找下一个。这里第三个参数（或者最后一个参数）为动态URI中取值，就会导致重定向去去查找，如果第三个值唯一确定的值就会默认到这个确定的值。
既然找到问题，上面的配置会导致循环重定向，那就想办法让他跳出‘循环’，再结合 伪静态实际最终也是要转原生URL的，肯定会用到rewrite，所以进行如下配置变更
# 保留做静态资源
location /view/ {
alias /data/project/pm-live-front/dist/;
}
# 统一路由入口，最后默认到一个采用 @ 实现Nginx内部跳转
location ~* /pm-live/(.*)/ {
root /data/project/pm-live-front/dist/;
try_files $uri $uri/ @pmliverewrite;
}
# 跳转到这里之后执行URL重写到默认的页面就行
location @pmliverewrite {
rewrite ^(/pm-live/[^/]+)/ $1/index.html last;
}
最终验证实现开发需要的需求
curl 'https://www.colinspace-demo.com/pm-live/pm-live-m/'
# 伪静态路由
curl 'https://www.colinspace-demo.com/pm-live/pm-live-m/livem/100/'
总结
通过上面的案例我们学习到以下知识点
1、root和alias对uri的处理有区别，alias会截取
2、Nginx的 alias 和try_files 两个之间存在互斥，不能同时配置
3、一般实现伪静态采用 root+try_files 就够了
4、但是存在动态URL的时候，需要用 root+try_files+单独带@的location的rewrite
5、凡是涉及到Nginx的location配置，那就需要了解Nginx location的几种方式及其优先级
6、另外就是Nginx URL的正则匹配，在实现rewrite重写的时候尤为重要
附加
Nginx location类型及优先级
精准匹配
- location = /uri 表示精准匹配，只要完全匹配上才能生效。记住只会匹配一个。
字符串匹配
最长匹配原则
- location /uri 不带任何修饰符，表示前缀匹配，忽略大小写。但是优先级在正则匹配之后
- location ^~ /uri 开头对URL路径进行前缀匹配，并且在正则之前。一旦匹配到最长匹配，则不再查找其他匹配项
正则匹配
- location ~ pattern 开头表示区分大小写的正则匹配
- location ~* pattern 开头表示不区分大小写的正则匹配，如果有多个location匹配，则选择匹配最长的那个
通用匹配
- location / 通用匹配，任何未匹配到其他location的请求都会匹配到
所以这几个的优先级为：
=(精确匹配) > ^~(普通字符匹配) > ~*(正则匹配) > 完全路径 > /
源站地址：http://blog.colinspace.com/2022/03/09/nginx-alias-root-and-try-files/
人生漫漫路，坚持一起学~