因为我知道，实践才是实现真理的唯一标准。
在工作的几年中，项目开发都是在别人的带领下，关于什么技术选型，什么项目架构搭建等一系列步骤，基本上跟自己关系不大，然后自己就只有默默的在开发过程中擦边学习；那么其中的难点，痛点，不经历过，是不知道什么滋味的。就会造成：
所以只有真正的实践过后，你才能更好的应对上面的局面，展现出更好的自己。
在部署之前，你肯定需要了解一些关于nginx的知识。
nginx介绍就不用多说了吧，网上一大堆，而且我也解释不清楚。只需要知道，nginx是一台高性能，轻量级的服务器即可。
列述一下我在此过程中学到的nginx的知识。
mac电脑查看本地安装nginx的信息
输入的网址叫做请求URI，nginx用请求URI与location中配置的URI做匹配。
请求URI分为两种情况（重定向）：
针对第二种情况，又可以分为两种情况：
注意要点：但是如果想这两种请求对应不同的处理，就要明确增加不带/结尾的location配置
使用root，实际的路径就是：root值+location值。
使用alias，实际的路径就是：alias值。
#测试路径xxx/static/a.pnglocation/static/{root/var/www/app/;#/var/www/app+/static/+a.png(三部分)}location/static/{alias/var/www/app/static/;#/var/www/app/static/+a.png（两部分）}alias后面必须要用“/”结束，是错误的结论，加不加都是一样。
alias在使用正则匹配时，必须捕捉要匹配的内容，并在指定的内容处使用。
alias只能位于location块中，root可以不放在location中。
location匹配机制是存在优先级的，其顺序如下：
就是简单看成js中的switch语句，依次判断下来。location/就类似default逻辑
location/subapp{aliashtml/dist/;indexindex.html;}配置try_files，解决刷新会404location/subapp{try_files$uri$uri//index.html;}代理proxy_pass是否需要添加/在nginx中配置proxy_pass代理转发时，
存在下面四种情况：
个人项目，采用的是微前端（qiankun），那么就会存在多个应用。当然该项目只有两个应用：
这里就不讲解qiankun一步一步的怎么使用了，当有需要的时候，就列出关键的部分代码即可。
因为存在多个应用，那么在部署的时候就会存在多个方案。
在开始之前，先看看个人nginx的目录结构
├─root│├─copyer#前端代码││├─main#主应用│││└─build││└─subppp#子应用集合（如果存在多个，继续往该文件夹添加）││└─management│└─copyer_server#后端代码该项目只涉及到两个应用，目录结构就如上：
就是每个应用单独开端口来部署，也就是所谓的多加一层server层。
主应用默认部署在80端口上；
子应用部署在7241端口上；（前提是，该端口已经被添加在云服务器的安全组中，在这里我找了好久的问题）。
那么就会在nginx.conf写出如下配置：
在上面的一步中，需要配置跨域信息；因为在客户端，端口不一样，就不满足同源策略，就会产生跨域。
在前端代码中，也需要注意两点（就直接展示截图了）：
第一点：主应用读取子应用的入口文件。
根据环境区分子应用的入口路径。
import.meta.env是vite项目中读取配置文件信息
第二点：子应用中vite.config.ts的base的修改。
在vite.config.ts中配置开发或生产环境服务的公共基础路径是base属性，默认值为/。
配置该属性，影响的是读取静态文件的资源路径。
看一下，打包后的index.html文件
在读取静态资源的路径都拼接了base。
为什么需要拼接base呢？
简单的来说，要明确根目录在哪里。
所以就需要精确的指定文件读取的路径，这也就是为什么需要配置base。
该方案就是把所有应用部署在一个端口，主应用的location为/，针对子应用采用使用二级目录的方式（即：location为/xxx）。
所以该方案就是一个server，多加一层location的方式，那么就会在nginx.conf写出如下配置：
简单解释一下：
location匹配存在优先级的关系，那么当请求uri为/subapp时，就会去匹配location为/subapp信息，然后通过alias的方式获取路径，读取文件信息。
也是会存在上面两点的问题：
主应用：
qiankun的入口文件配置：
子应用：
打包出来的html文件：
发现子应用的获取静态资源路径都是/subapp/management开始的，也就成功匹配了location为/subapp，那么就会去/root/copyer/subapp/management下找文件，显而易见能成功找到。
上面的两种部署方案，个人尝试并都成功了。当然，可能其中还有些细节性的东西或者现象没有处理好，那么就请码友们多多指教，学习学习。
通过上面的两种部署方式都可以主应用访问，也能子应用单独访问；至于具体怎么部署，看个人的习惯或者开发的需求。
第一种，没有文件目录要求，就是每个应用单独部署。（多个server）
第二种，就是nginx里面的文件目录需要按照一定的规范。（多个location）
在上面的操作之后，就能通过域名进行对项目进行访问了。但是，当点击之后，可能也会发现一个问题，就是接口调不通。就比如说：
你会发现，该接口，获取的资源是一个html文件。为什么呢？
因为在上面location中都没有配置/api，当寻找不成功时，就会进入默认匹配/，从而也就解释了为什么返回html文件。
所以，为了解决上面的情况，就需要通过代理，代理到写的后台服务器中，获取对应的资源。
该系统就是采用的koa技术栈开发的服务器，利用pm2部署在nginx上的。
通过上面的一系列步骤，就可以把自己的项目完整的运行在自己个域名上面，感觉非常棒。
其实，对于大部分前端来说，是基本上不会接触nginx的；因为公司一般都是运维人员进行操作，再不济也是后端人员进行操作。所以说，我（前端人员）对nginx的看法就是可以了解，但是不必过分的深究，当然也不阻止你深究（不要太卷了）。
类似nginx的压缩，缓存等等，等到后面使用的时候，再去研究吧，对nginx的了解到此结束。
本篇就到此结束了，如果觉得对你有点帮助的，就点个赞呗~~~。