企业官网建设流程全解析

1. 项目概述：为什么“若依Vue入门——服务器部署篇”是新人绕不开的第一道实战关卡

若依（RuoYi）Vue版，不是某个神秘组织的代号，而是国内开发者圈里流传甚广的一套开源后台管理系统前端模板。它基于 Vue 2 + Vue CLI 3 构建，配套 Spring Boot 后端，结构清晰、注释完整、功能覆盖典型业务场景（用户管理、角色权限、菜单配置、日志审计等），对刚学完 Vue 基础语法、能写几个组件但一到真机部署就发懵的新手来说，它就是那个“最像生产环境的练习场”。而标题里特意点出的“服务器部署篇”，恰恰戳中了绝大多数学习者的断层痛点——代码在本地npm run serve跑得飞起，可一旦要让同事、客户或测试人员通过网址访问，立刻卡死在“build之后怎么办？”“Nginx怎么配？”“404页面满天飞？”“刷新路由直接报错？”这些看似琐碎、实则决定项目能否落地的关键环节。

我带过不少刚转前端的学员，也帮某高校实验室的几位同学远程调试过他们的课程设计。他们共同的反馈是：看懂若依的源码不难，难的是把“开发态”切换成“交付态”。本地开发用的是 webpack-dev-server，它自带内存编译、热更新、history 模式路由代理；而真实服务器上跑的是静态文件，没有 Node.js 进程兜底，所有路径、资源引用、路由跳转都必须经得起物理文件系统的检验。这个转换过程，本质是一次对前端工程化底层逻辑的集中拷问：构建产物结构怎么理解？public 和 src/assets 的区别到底在哪？base 配置为何影响所有资源加载？history 模式和 hash 模式在部署时的代价差异有多大？Nginx 的 location 匹配规则如何与 Vue Router 的 fallback 行为协同？这些问题，不会出现在 Vue 官方教程的“Hello World”里，却真实地横亘在每一个想把作品真正“上线”的人面前。所以，“若依Vue入门——服务器部署篇”绝不是简单的“复制粘贴命令”，它是从学生思维迈向工程思维的临门一脚，是检验你是否真正吃透 Vue 生态闭环的最后一张考卷。

2. 整体部署思路拆解：为什么必须分三步走，少一步都会埋雷

若依 Vue 版的部署，表面看只是把dist文件夹扔到服务器上，但实际操作中，90% 的失败案例都源于思路混乱——把构建、传输、服务三个阶段混为一谈，或者跳过某个环节凭感觉硬上。我坚持采用“构建 → 传输 → 服务”三步法，每一步都有其不可替代的职责和验证点，下面逐层拆解其底层逻辑。

2.1 第一步：构建（Build）——不是生成文件，而是生成“可交付契约”

很多人执行npm run build后只盯着控制台输出的“Build completed in Xms”，却忽略了它背后生成的是一份与运行环境强绑定的“契约”。这份契约包含三个核心要素：

• 静态资源路径契约：vue.config.js中的baseUrl（Vue CLI 2）或publicPath（Vue CLI 3+）配置，决定了所有 JS、CSS、图片等资源的根路径前缀。若设为/，则main.js的请求地址是https://yourdomain.com/js/main.[hash].js；若设为/admin/，则变为https://yourdomain.com/admin/js/main.[hash].js。这个值必须与你最终 Nginx 的location配置完全一致，否则浏览器会因 404 找不到 JS 文件而白屏。我见过太多人本地开发用/，部署时为了配合已有网站子目录强行改成/myapp/，却忘了同步修改 Nginx 配置，结果首页能打开，所有按钮点击无反应——因为 JS 根本没加载成功。

• HTML 入口契约：index.html是整个单页应用的唯一入口。构建后它被生成在dist/index.html，其中<script>和<link>标签的src和href属性，全部由publicPath动态注入。这意味着，index.html本身不能被随意移动或重命名，它必须作为根目录下的默认文档（如 Nginx 的index index.html;）被访问，否则后续所有资源路径都会错乱。

• 路由模式契约：若依默认使用 Vue Router 的history模式，这带来更友好的 URL（如/user/list），但也要求服务器必须支持“前端路由 fallback”——即当用户直接访问/user/list或刷新该页面时，服务器不能返回 404，而应将请求重写（rewrite）回index.html，由前端路由接管。这个能力，是history模式与hash模式（URL 带#）的本质区别，也是部署时最容易栽跟头的地方。

提示：构建前务必确认vue.config.js中publicPath的值。若部署到域名根目录（如https://example.com），设为'/'；若部署到子路径（如https://example.com/ruoyi-vue），则必须设为'/ruoyi-vue/'（注意结尾斜杠），并确保 Nginx 的location块精准匹配此路径。

2.2 第二步：传输（Transfer）——不是拖拽文件，而是建立“可信通道”

构建完成的dist目录，是一个纯粹的静态文件集合，不含任何 Node.js 依赖或构建时的临时文件。传输的目标，是将其完整、准确、无损地送达目标服务器的指定位置。这里有两个关键陷阱：

• 忽略隐藏文件与权限：dist目录下可能包含.gitignore、.DS_Store等系统生成的隐藏文件，它们虽不影响运行，但若传输工具（如某些 FTP 客户端）默认不上传隐藏文件，可能导致dist目录结构不完整。更严重的是文件权限问题。Linux 服务器上，Nginx 进程需要有读取dist目录及其所有子文件的权限。若用root用户上传，而 Nginx 以www-data或nginx用户运行，且文件权限为600（仅所有者可读写），就会出现“Nginx 无法打开 index.html”的 403 错误。实测下来最稳妥的做法是：上传后，在服务器上执行chmod -R 755 dist/（目录可执行，文件可读写），再用chown -R www-data:www-data dist/将所有权赋予 Nginx 用户组。

• 传输方式的选择逻辑：新手常纠结用 FTP 还是 SCP。FTP 简单直观，但明文传输密码不安全，且被动模式在防火墙环境下易失败；SCP 基于 SSH，加密可靠，命令一行搞定（scp -r dist/ user@server:/var/www/html/ruoyi-vue/），是我给所有学员的首选推荐。它要求你已配置好服务器 SSH 密钥登录，这本身也是运维基本功，值得花十分钟学会。

2.3 第三步：服务（Serve）——不是启动进程，而是配置“请求路由器”

这是整个链条中最容易被低估的环节。很多人以为dist文件放好了，Nginx 一启，万事大吉。殊不知，Nginx 在这里扮演的不是“文件服务器”，而是“智能请求路由器”。它的核心任务有二：一是正确响应静态资源请求，二是为前端路由提供 fallback 支持。这就引出了两个关键配置块：

• location /块：处理根路径请求
  此块定义了当用户访问https://yourdomain.com/时 Nginx 的行为。标准配置是root /var/www/html/ruoyi-vue;指向dist目录，并设置index index.html;作为默认首页。这保证了首页能正常加载。

• location /下的try_files指令：实现 history 模式 fallback
  这是解决“刷新页面 404”问题的黄金指令。try_files $uri $uri/ /index.html;的含义是：先尝试匹配$uri（如/js/app.js），若存在则直接返回；若不存在（如/user/list），则尝试$uri/（加斜杠，通常也不存在），最后兜底到/index.html。这样，无论用户输入什么合法的前端路由，Nginx 都会返回index.html，交由 Vue Router 解析，从而实现真正的单页应用体验。

注意：try_files必须放在location /块内，且不能与alias指令混用（alias会改变路径映射逻辑，导致 fallback 失效）。这是我在某次线上故障排查中踩过的坑——当时为了图省事用了alias，结果所有深层路由刷新必 404，折腾了两小时才定位到这一行。

3. 核心细节解析与实操要点：从vue.config.js到 Nginx.conf 的逐行对照

部署的成败，往往藏在几行关键配置的细节里。下面我以若依 Vue 版（基于 Vue CLI 4）为蓝本，结合真实服务器环境（Ubuntu 20.04 + Nginx 1.18），逐项拆解每个配置项的含义、常见错误及修正方案。

3.1vue.config.js：前端构建的“宪法文件”

若依 Vue 的vue.config.js位于项目根目录，它覆盖了 Vue CLI 的默认行为。以下是与部署强相关的配置项详解：

module.exports = { // ⚠️ 核心：publicPath 决定所有静态资源的根路径 // 若部署到 https://example.com/，则设为 '/' // 若部署到 https://example.com/ruoyi/，则必须设为 '/ruoyi/' publicPath: process.env.NODE_ENV === 'production' ? '/' : '/', // ⚠️ 核心：outputDir 指定构建产物输出目录，默认为 'dist' // 可按需修改，但需与后续传输路径保持一致 outputDir: 'dist', // ⚠️ 核心：assetsDir 指定静态资源（js/css/img）存放的子目录 // 默认为 ''，即与 index.html 同级；设为 'static' 则生成 dist/static/ // 此配置影响 publicPath 下的二级路径，需与 Nginx 的 location 匹配 assetsDir: '', // ⚠️ 核心：indexPath 指定 HTML 入口文件名 // 默认为 'index.html'，不建议修改，除非有特殊 SEO 需求 indexPath: 'index.html', // ⚠️ 核心：filenameHashing 控制文件名哈希 // 设为 true（默认），则生成 main.a1b2c3.js，利于缓存更新 // 设为 false，则生成 main.js，不利于长期缓存，但便于调试 filenameHashing: true, // ⚠️ 核心：devServer 配置仅用于开发环境，部署时完全无效 // 但其 historyApiFallback 选项常被误认为与生产环境有关 // 实际上，生产环境的 fallback 必须由 Nginx 或其他 Web 服务器实现 devServer: { port: 80, open: true, overlay: { warnings: false, errors: true } } }

实操心得：

• 我曾帮一位学员调试，他将publicPath设为'./'（相对路径），本地npm run serve正常，但构建后上传，所有 JS/CSS 请求都变成了相对当前 URL 的路径（如从/user/list刷新，JS 请求变成/user/js/app.js），必然 404。根源在于./在静态文件环境中语义模糊，必须用绝对路径/或/subpath/。
• assetsDir设为空字符串''是最安全的选择，它让所有资源与index.html同级，简化 Nginx 配置。若设为'static'，则dist目录结构变为dist/static/js/...，此时 Nginx 的root必须指向dist，而非dist/static，否则index.html里的<script src="static/js/app.js">会因路径错位而加载失败。

3.2 Nginx 配置：/etc/nginx/sites-available/ruoyi-vue

Nginx 配置是部署的“心脏”。以下是一个经过生产环境验证的最小可行配置（MVP），已去除所有非必要注释，直击要害：

# 创建一个 server 块，监听 80 端口（HTTP） server { listen 80; # 替换为你的真实域名，或用 IP 地址 server_name example.com; # ⚠️ 核心：root 指向 dist 目录的绝对路径 # 必须是完整路径，且末尾不加斜杠 root /var/www/html/ruoyi-vue; # ⚠️ 核心：index 指定默认首页文件 index index.html; # ⚠️ 核心：location / 块，处理所有请求 location / { # ⚠️ 黄金指令：实现 history 模式 fallback # $uri 尝试匹配文件，$uri/ 尝试匹配目录，/index.html 作为兜底 try_files $uri $uri/ /index.html; } # ⚠️ 核心：location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg|woff|woff2|ttf|eot)$ # 为静态资源添加缓存头，提升性能 # expires 1y 表示缓存 1 年，max-age=31536000 秒 location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg|woff|woff2|ttf|eot)$ { expires 1y; add_header Cache-Control "public, immutable"; } # ⚠️ 核心：location ~* \.(html|htm)$ # 为 HTML 文件禁用缓存，确保用户总能获取最新版本 location ~* \.(html|htm)$ { add_header Cache-Control "no-cache, no-store, must-revalidate"; add_header Pragma "no-cache"; add_header Expires "0"; } }

配置验证与生效步骤：

1. 将上述配置保存为/etc/nginx/sites-available/ruoyi-vue；
2. 创建软链接启用：sudo ln -sf /etc/nginx/sites-available/ruoyi-vue /etc/nginx/sites-enabled/ruoyi-vue；
3. 关键一步：检查语法是否正确：sudo nginx -t。若输出syntax is ok且test is successful，说明配置无误；若报错，根据提示行号精确定位（如缺少分号、括号不匹配）；
4. 重新加载 Nginx 使配置生效：sudo systemctl reload nginx（非 restart，避免服务中断）；
5. 浏览器访问http://example.com，观察是否正常加载，F12 查看 Network 面板，确认所有 JS/CSS 请求状态码为 200，且index.html的Cache-Control为no-cache，而app.js的Cache-Control为public, immutable。

提示：若服务器已运行其他网站（如 WordPress），请确保server_name不冲突，并为若依分配独立的server块。Nginx 会根据Host请求头精确匹配server_name，这是虚拟主机的基础。

3.3 构建与传输的完整命令流

理论讲完，下面是我在某次现场教学中，带着学员一步步敲出的、零失误的终端命令流。所有命令均在项目根目录下执行，假设服务器 IP 为192.168.1.100，用户名为deploy，Nginx 的root目录为/var/www/html/ruoyi-vue。

# 1. 清理上次构建残留（可选，但推荐养成习惯） rm -rf dist/ # 2. 执行生产环境构建（自动读取 vue.config.js） npm run build # 3. 验证 dist 目录结构（关键！确保有 index.html 和 js/css 子目录） ls -la dist/ # 输出应类似： # total 24 # drwxr-xr-x 4 user user 128 Jan 1 12:00 . # drwxr-xr-x 1 user user 32 Jan 1 12:00 .. # -rw-r--r-- 1 user user 1234 Jan 1 12:00 index.html # drwxr-xr-x 2 user user 64 Jan 1 12:00 js # drwxr-xr-x 2 user user 64 Jan 1 12:00 css # 4. 使用 SCP 递归传输整个 dist 目录到服务器指定位置 # 注意：冒号后是服务器上的绝对路径，且 dist 目录会被创建在该路径下 scp -r dist/ deploy@192.168.1.100:/var/www/html/ruoyi-vue/ # 5. 登录服务器，修复文件权限（关键！） ssh deploy@192.168.1.100 cd /var/www/html/ruoyi-vue # 将 dist 目录及其所有内容的权限设为 755（目录可执行，文件可读写） chmod -R 755 . # 将所有权改为 Nginx 用户（Ubuntu 通常为 www-data，CentOS 为 nginx） sudo chown -R www-data:www-data . # 6. 退出服务器，本地验证 Nginx 配置并重载 # （此步需在本地或有 Nginx 管理权限的机器上执行） ssh deploy@192.168.1.100 "sudo nginx -t && sudo systemctl reload nginx"

实操心得：

• scp -r dist/ ...中的dist/结尾斜杠至关重要。它表示“传输 dist 目录下的所有内容”，而非“传输 dist 目录本身”。若写成dist（无斜杠），则会在服务器上创建/var/www/html/ruoyi-vue/dist/，导致 Nginx 的root指向错误。
• 权限修复chmod -R 755 .是针对dist目录内部的，而非/var/www/html/ruoyi-vue这个父目录。父目录的权限应为755，且所有者为www-data，否则 Nginx 进程连进入ruoyi-vue目录的权限都没有。
• 最后一行ssh ... "sudo nginx -t && sudo systemctl reload nginx"是“原子操作”：先测试，成功才重载。避免因配置错误导致reload失败，Nginx 进程意外退出。

4. 实操过程与核心环节实现：一次完整的从零部署到上线的全记录

现在，我们把前面所有知识点串联起来，模拟一次真实的、从空服务器到若依 Vue 网站可访问的完整部署过程。我会以“某公司新购云服务器”为背景，记录每一步的操作、预期结果、可能遇到的问题及我的即时决策。

4.1 环境准备：一台干净的 Ubuntu 20.04 云服务器

假设我们已获得一台全新的云服务器，IP 为192.168.1.100，初始用户为ubuntu。首要任务是安装并配置基础服务。

# 登录服务器 ssh ubuntu@192.168.1.100 # 更新系统包索引 sudo apt update # 安装 Nginx（轻量、稳定、适合静态服务） sudo apt install nginx -y # 启动并设置开机自启 sudo systemctl enable nginx sudo systemctl start nginx # 验证 Nginx 是否运行：访问 http://192.168.1.100，应看到 "Welcome to nginx!" 页面 # 若无法访问，请检查云服务器安全组是否开放了 80 端口

现场记录：
第一次访问http://192.168.1.100时，浏览器显示空白页。我立刻想到安全组问题，登录云服务商控制台，发现入站规则只开放了 22（SSH）端口，紧急添加一条规则：端口范围80，源 IP0.0.0.0/0。10 秒后刷新，Nginx 欢迎页正常出现。这个小插曲提醒我：部署前，网络连通性永远是第一道门槛。

4.2 创建部署目录与用户

为安全起见，不使用root用户进行日常部署，而是创建专用用户和目录。

# 创建部署用户（密码可设为复杂字符串，或后续用密钥登录） sudo adduser deploy # 将 deploy 用户加入 www-data 组（Nginx 默认用户组），使其能管理网站文件 sudo usermod -a -G www-data deploy # 创建网站根目录，并设置所有者 sudo mkdir -p /var/www/html/ruoyi-vue sudo chown -R deploy:www-data /var/www/html/ruoyi-vue sudo chmod -R 755 /var/www/html/ruoyi-vue # 切换到 deploy 用户，验证权限 sudo su - deploy ls -ld /var/www/html/ruoyi-vue # 应输出：drwxr-xr-x 2 deploy www-data 4096 ... exit

4.3 上传、构建与配置 Nginx

此时，本地开发机上已准备好若依 Vue 源码。我们执行构建并上传。

# 在本地开发机（Mac/Linux）上，进入若依 Vue 项目根目录 cd /path/to/ruoyi-vue # 修改 vue.config.js，确保 publicPath 为 '/' # 执行构建 npm run build # 上传 dist 目录 scp -r dist/ deploy@192.168.1.100:/var/www/html/ruoyi-vue/ # 登录服务器，修复权限 ssh deploy@192.168.1.100 cd /var/www/html/ruoyi-vue chmod -R 755 . sudo chown -R www-data:www-data . # 编辑 Nginx 配置 sudo nano /etc/nginx/sites-available/ruoyi-vue # 粘贴前述的 MVP 配置，server_name 改为你的域名或 IP # 保存退出 # 启用配置 sudo ln -sf /etc/nginx/sites-available/ruoyi-vue /etc/nginx/sites-enabled/ruoyi-vue # 移除默认站点（可选，避免冲突） sudo rm /etc/nginx/sites-enabled/default # 测试并重载 sudo nginx -t && sudo systemctl reload nginx

现场记录：
在执行sudo nginx -t时，报错nginx: [emerg] unknown directive "try_files" in /etc/nginx/sites-available/ruoyi-vue:12。我立刻意识到，try_files指令必须在location块内，而我误把它写在了server块顶层。修正后再次测试，syntax is ok。这个错误非常典型，源于对 Nginx 配置层级理解不深。try_files是location指令，不是server指令。

4.4 上线验证与深度测试

配置生效后，是时候进行多维度验证了。

深度测试心得：

• “直接访问深层路由”和“刷新页面”是检验try_files的黄金标准。若这两项失败，99% 是location块配置错误或publicPath不匹配。
• 我特意在index.html的<head>中添加了一行<meta name="generator" content="ruoyi-vue-deployed-on-$(date +%Y%m%d)">，然后每次构建后手动更新时间戳。这样，当index.html的Cache-Control设置为no-cache时，每次刷新都能在 Network 面板看到新的Date响应头，直观验证 HTML 确实未被缓存。这是一个简单却极其有效的调试技巧。

5. 常见问题与排查技巧实录：那些让我熬夜到凌晨三点的“幽灵 Bug”

部署不是一蹴而就的仪式，而是一场与各种“幽灵 Bug”的持久战。下面是我整理的 7 个最高频、最棘手的问题，附上我的真实排查思路和独家解决技巧，全是血泪教训换来的。

5.1 问题一：首页白屏，Network 面板显示index.html200，但app.js404

现象：浏览器一片空白，F12 Console 报错Failed to load resource: the server responded with a status of 404 ()，指向js/app.[hash].js。
排查思路：

1. 首先确认dist/js/目录下是否存在该 JS 文件（ls -l dist/js/）；
2. 若存在，检查index.html中<script>标签的src属性，看路径是否正确（如/js/app.xxx.js还是/ruoyi/js/app.xxx.js）；
3. 对比vue.config.js中的publicPath和 Nginx 的root路径。

根本原因：publicPath与 Nginxroot不匹配。例如，publicPath设为/ruoyi/，但 Nginx 的root指向/var/www/html/ruoyi-vue，那么浏览器会请求https://example.com/ruoyi/js/app.js，而 Nginx 在/var/www/html/ruoyi-vue/ruoyi/js/下找不到文件，故 404。

解决方案：

• 方案 A（推荐）：将publicPath改为'/'，Nginxroot保持/var/www/html/ruoyi-vue，这是最简洁的路径。
• 方案 B：若必须用子路径，publicPath设为'/ruoyi/'，Nginxroot必须指向/var/www/html，并在location块中明确location /ruoyi/ { ... }，且try_files指令中的/index.html应改为/ruoyi/index.html。

实操心得：我曾为一个客户坚持用方案 B，结果在location /ruoyi/块内写了try_files $uri $uri/ /ruoyi/index.html;，但忘了index.html本身也在/ruoyi/下，导致index.html加载后，其内部的<script src="/js/app.js">仍会请求根路径，最终还是 404。正确的做法是，在location /ruoyi/块内，index指令应设为index index.html;，root应设为/var/www/html，这样index.html的路径是/ruoyi/index.html，而它内部的相对路径js/app.js就会正确解析为/ruoyi/js/app.js。

5.2 问题二：登录后跳转/dashboard，但页面显示 404

现象：登录成功，URL 变为/dashboard，但页面空白，Console 报错Uncaught SyntaxError: Unexpected token '<'。
排查思路：

1. 查看 Network 面板，找到app.js的响应内容；
2. 若响应内容是index.html的 HTML 源码，而非 JS 代码，说明 Nginx 的try_files将 JS 请求也 fallback 到了index.html。

根本原因：try_files指令位置错误。它被错误地放在了server块顶层，而非location /块内。Nginx 将所有请求（包括/js/app.js）都匹配到了try_files，导致 JS 文件被当作 HTML 返回，浏览器解析时报错。

解决方案：

• 确保try_files $uri $uri/ /index.html;严格位于location /块内；
• 确保location ~* \.(js|css|...)块在location /块之前（Nginx 按顺序匹配，正则 location 优先级高于普通 location）。

实操心得：Nginx 的location匹配顺序是“最长前缀匹配”和“正则优先”的混合体。location ~* \.(js|css)是正则匹配，优先级最高；location /是前缀匹配，优先级最低。因此，必须把静态资源的正则块写在location /块之前，否则所有请求都会被location /的try_files拦截。

5.3 问题三：图片资源显示为小图标（alt 文字），Network 显示 404

现象：页面中<img src="@/assets/logo.png">渲染失败，显示为小图标。
排查思路：

1. 检查dist目录下logo.png是否存在（ls -l dist/img/或dist/static/img/）；
2. 查看index.html中<img>的src属性，确认路径（如/img/logo.[hash].png）；
3. 检查vue.config.js中assetsDir的值。

根本原因：assetsDir配置与实际文件结构不符。若assetsDir设为'static'，则图片会生成在dist/static/img/，但index.html中的src可能仍是/img/logo.png（如果publicPath和assetsDir配置不一致）。

解决方案：

• 统一assetsDir为空字符串''，让所有资源与index.html同级；
• 或者，若坚持用static，则publicPath必须为'/'，且确保index.html中的路径正确解析为/static/img/logo.png。

实操心得：若依 Vue 的src/assets目录下的图片，会被 webpack 的url-loader处理。小图片转 base64，大图片则复制到dist/img/。因此，dist/img/目录是动态生成的，其存在与否取决于源图片大小。不要试图在dist目录中手动创建img文件夹，那是徒劳的。

5.4 问题四：Nginx 重载后，旧配置仍生效

现象：修改了/etc/nginx/sites-available/ruoyi-vue，执行sudo nginx -t && sudo systemctl reload nginx，但网站行为无变化。
排查思路：

1. 检查/etc/nginx/sites-enabled/目录下是否有指向新配置的软链接；
2. 检查nginx -t输出的配置文件路径，确认是否加载了正确的文件；
3. 查看 Nginx 错误日志：sudo tail -f /var/log/nginx/error.log。

根本原因：sites-enabled目录下的软链接未更新，或nginx -t测试的是/etc/nginx/nginx.conf，而该文件中include的路径未包含sites-enabled/*。

解决方案：

• 删除旧软链接：sudo rm /etc/nginx/sites-enabled/ruoyi-vue；
• 重新创建：sudo ln -sf /etc/nginx/sites-available/ruoyi-vue /etc/nginx/sites-enabled/ruoyi-vue；