本地npm run dev跑得好好的build也没报错结果传到服务器上一打开全白屏。这个场景我见过太多次了而且不只是刚转行的新手在职前端一不小心也会踩进去。所以这篇就从一个真实的Vue项目出发从打包到上线把部署到阿里云服务器的每一步都拆开来讲包括Nginx配置、history路由处理、反向代理、HTTPS、Docker部署方案还有我在实战里踩过的各种坑。这篇内容适合三类人一是刚接触部署、只知道“npm run build然后传上去”的前端开发二是自己做个人项目、想独立完成服务器上线的全栈学习者三是团队里需要建立标准化前端部署流程的同学。看完之后你不仅能把Vue项目顺利跑在阿里云服务器上还能理解每一步背后的原理以后再遇到白屏、404、跨域这类部署问题能自己快速定位。1. 部署前必须做好的三件事很多人在部署这一步翻车不是因为操作多难而是准备工作没做齐。服务器没买对、域名没备案、本地还没验证build产物就直接传上去了结果一上线全是问题。这里我先把部署前最容易忽略的三件事讲清楚。1.1 服务器配置与系统选择如果是个人学习项目或者小流量应用阿里云的轻量应用服务器完全够用2核2G内存、3M带宽的配置跑一个Vue静态站点加个轻后端绰绰有余。如果是正式上线的业务建议ECS起步规格选2核4G因为除了前端静态文件后面还有Nginx、后端服务、日志采集这些要占资源。带宽这块别贪小便宜3M带宽并发一高就很吃力预算允许直接上5M。系统镜像方面我习惯选Ubuntu 22.04 LTS或者Debian系列因为包管理工具apt比某些老系统好用很多安装Nginx、配置证书都省事。阿里云控制台创建实例的时候会自动生成一个安全组默认只放行了22端口SSH用所以购买时段落里第一件事就是把安全组的80和443端口加入方向规则授权对象填0.0.0.0/0。这一步不做后面Nginx配得再好公网也访问不了。1.2 域名、解析与备案我先说结论只是自己测试可以用服务器公网IP加非标准端口访问正式做项目一定要绑定域名并且完成备案。国内服务器有个硬性规则域名解析到服务器后必须通过ICP备案才能正常使用80和443端口备案流程一般要10到20个工作日所以域名和备案一定要提前规划别等项目写完了才想起来。域名解析很简单在阿里云DNS控制台添加一条A记录主机记录填www或者记录值填服务器公网IPTTL默认就行。如果你没备案又想先看效果可以把Nginx监听端口改成8080之类的非标准端口在安全组里放行对应端口再用http://IP:8080访问。这种方案临时验证可以但线上正式环境我强烈不建议这么做一个是浏览器会有“非标准端口”的怪提示另一个是搜索引擎收录、微信分享这类场景都很挑剔。1.3 先确认你的项目在本机“真的能打包”很多人部署失败其实问题在打包阶段就埋下了。dev模式跑得好好的不代表build产物没问题。我在本地验证的流程是固定的npm run build npx serve -s dist -l 8080serve -s的意思是SPA路由重写访问不存在的路径会回退到index.html这和线上Nginx的try_files作用类似。打开http://localhost:8080把页面点一圈再看看Network面板里有没有404的资源。这一步能提前发现组件库样式缺失、图片路径写死、接口地址被硬编码进代码之类的问题。确认无误之后再进入上传服务器的阶段。2. Vue项目打包别小看一个build打包这一步看着就一行命令但里面的配置细节能直接影响线上表现。这一节我会把vue.config.js里几个关键项的原理讲透并给你一套可以直接抄的配置。2.1 打包前必须检查的配置文件Vue CLI项目根目录下的vue.config.js是打包的“总开关”。我一般会这样配置// vue.config.js const { defineConfig } require(vue/cli-service) module.exports defineConfig({ transpileDependencies: true, publicPath: /, outputDir: dist, assetsDir: static, productionSourceMap: false, lintOnSave: false })这里重点解释四个项publicPath静态资源引用时的基础路径。默认/表示资源路径是/static/js/xxx.js适合部署在域名根目录。如果你要用http://ip:8080/my-app这种子路径访问就得改成/my-app/或者用相对路径./。很多白屏问题就是这里配置不对引起的。assetsDir: static把所有js、css、图片集中到static目录下方便后面Nginx按路径做缓存策略。productionSourceMap: false生成环境关掉sourceMap能显著减小dist目录体积也避免源码映射暴露在公网。transpileDependencies: true有些第三方依赖没做好ES5兼容打开这个能降低一部分低版本浏览器报错概率。如果你的项目用的是Vite对应的是vite.config.js里的base字段作用和publicPath一样部署在根目录就填/子路径就填相对路径。2.2 接口地址别写死环境变量要会用我发现很多部署失败的项目接口地址是硬写在代码里的比如axios.defaults.baseURL http://192.168.1.100:8080/api。打包的时候把这个IP一起打进去环境一换全乱套。正确做法是区分环境变量。在项目根目录创建两个文件# .env.development本地开发 VUE_APP_ENV development VUE_APP_BASE_URL /api # .env.production线上构建 VUE_APP_ENV production VUE_APP_BASE_URL /api代码里统一用process.env.VUE_APP_BASE_URL来拼接接口地址。为什么要统一成/api因为线上我们通常走Nginx反向代理把/api开头的请求转发到后端服务这样浏览器只和同源域名通信不产生跨域问题。这个机制后面第5节会详细讲现在先记住这个习惯接口地址一律写相对路径不要写死IP和端口。2.3 打包后先本地预览dist产物打包完成后dist目录不能只看一眼文件在不在要真实运行起来验证。一方面用上一节说的npx serve -s dist -l 8080跑起来看页面另一方面做一次“资源路径体检”按F12打开Network刷新页面看到js/css文件的状态码全是200页面控制台没有红色报错才算通过。这里我再补充一个判断静态资源路径对不对的小技巧。如果你在浏览器地址栏访问http://localhost:8080/页面正常但访问http://localhost:8080/static/js/index.js出现404说明资源基础路径和实际部署路径对不上。反之如果页面里加载的js路径变成了/static/static/js/xxx.js这种双层的就是assetsDir和publicPath组合出了问题。出现这类情况优先检查vue.config.js里的路径配置。3. 把dist上传到服务器的正确姿势本地验证通过接下来就是把dist目录传到服务器。这一步看似简单但目录选错、上传工具不对也会给后面埋坑。3.1 选择合理的服务器目录我见过很多人把Vue项目的dist直接解压到/usr/share/nginx/html和Nginx默认页面混在一起。这样做不是不能跑但后续维护很痛苦项目多了分不清权限混乱回滚也麻烦。我推荐的目录结构是/var/www/ └── vue-app/ # 每个独立项目一个目录 ├── index.html └── static/ ├── css/ └── js/创建目录的命令sudo mkdir -p /var/www/vue-app sudo chown -R $USER:$USER /var/www/vue-appchown这一步是为了让当前用户有写权限不然scp上传的时候会提示Permission denied。如果你用的是root用户登录可以跳过权限修改但我是建议日常操作别用root跑服务权限太宽出问题不好追溯。3.2 上传方式对比与推荐命令上传方式有几种我列个表给你参考方式优点缺点适用场景scp简单直接系统自带断点续传差大文件慢小项目首次上传rsync增量同步自动覆盖差异命令参数略复杂每次迭代发布推荐WinSCP/FinalShell图形化可视化操作不适合自动化Windows图形化操作宝塔面板网页上传带文件管理额外安装面板程序不想折腾命令行的用户如果你习惯命令行直接用它是最省事的。首次上传用scpscp -r ./dist/* root你的服务器IP:/var/www/vue-app/后续迭代我更推荐rsync因为它是增量同步只传有变化的文件还能用--delete参数把远端多出来的旧文件删掉保证服务器上的内容和本地dist完全一致rsync -av --delete ./dist/ root你的服务器IP:/var/www/vue-app/注意./dist/结尾的斜杠不能省它表示同步目录内容本身而不是把dist这个文件夹再套一层。上传完成后在服务器上对比一下文件数量和总大小du -sh /var/www/vue-app find /var/www/vue-app -type f | wc -l和本地dist对比数值对得上再进行下一步。4. Nginx安装配置与history路由处理Nginx是整个Vue部署链路里的核心角色。它负责接收浏览器请求、返回静态文件、处理路由回退、做反向代理。这一步配置对了项目就算真正跑起来了。4.1 安装Nginx并理解配置目录Ubuntu系统安装Nginx很简单sudo apt update sudo apt install nginx -y sudo systemctl enable nginx sudo systemctl start nginx安装完以后浏览器直接访问服务器IP看到Welcome to nginx页面就说明服务正常。然后理解一下Nginx的目录结构这些文件各管各的文件/目录作用/etc/nginx/nginx.conf主配置文件全局参数/etc/nginx/sites-available/所有站点的配置文件都放这里/etc/nginx/sites-enabled/软链到available里的配置启用站点/etc/nginx/conf.d/另一种放置站点配置的目录与sites方式二选一Ubuntu的Nginx默认会启用/etc/nginx/sites-available/default这个默认站点。我习惯在sites-available里新建一个项目配置文件再软链到sites-enabled这样以后一个项目一个文件互不干扰。4.2 一个Vue项目的标准server配置块下面是一份我常用的Vue单页面应用Nginx配置可以直接复制把server_name换成你的域名server { listen 80; server_name www.example.com example.com; root /var/www/vue-app; index index.html; # 核心配置SPA路由回退 location / { try_files $uri $uri/ /index.html; } # 带hash的静态资源长缓存 location /static/ { expires 30d; add_header Cache-Control public, immutable; } # index.html 不缓存保证每次发布后用户拉到新版本 location /index.html { add_header Cache-Control no-cache; } }配置里最关键的是try_files $uri $uri/ /index.html;这一行。它的意思是当用户访问一个路径时先找有没有对应文件有就返回文件没有就尝试找目录都没有就回退到/index.html由前端路由接管。这一行决定了Vue Router的history模式能不能正常刷新我后面专门讲。写完配置后启用站点sudo ln -s /etc/nginx/sites-available/vue-app.conf /etc/nginx/sites-enabled/ sudo nginx -t sudo systemctl reload nginx注意每次改配置之前一定要先执行nginx -t检查语法提示“syntax is ok”再reload。这是我在服务器上养成的习惯可以避免改错配置导致Nginx直接挂掉。4.3 让Vue Router的history模式不再404这是Vue部署时最经典的一个问题本地用hash模式地址长这样/#/home上线前改成history模式地址变成/home然后在服务器上一刷新页面就404。原因其实不复杂。hash模式下#后面的内容纯属前端状态浏览器不会把它发给服务器history模式下/home是一个真实请求路径浏览器会把它发给服务器说“请给我这个页面”但服务器上根本没有/home这个文件只有/index.html于是Nginx默认返回404。try_files就是解决这个问题的找不到文件时回退到index.html让前端路由去解析路径。所以如果你用了history模式Nginx配置里必须有那行try_files。如果你还是坚持用hash模式那可以省掉回退逻辑但我个人建议新项目都上history毕竟URL更干净也更利于SEO和分享。4.4 静态资源缓存与gzip优化Vue打包出来的js/css文件名都带hash比如index.8f3d9c2a.js只要内容变了hash就变。这种文件非常适合长缓存用户第一次访问后下次直接从本地缓存读取不用再向服务器请求加载速度会有明显提升而index.html没有hash必须走no-cache否则用户可能一直拿到旧版本页面。这也解释了为什么缓存配置要分两套写不是所有文件都适合缓存几十年。gzip压缩可以进一步减少传输体积。在/etc/nginx/nginx.conf的http块中加上gzip on; gzip_min_length 1k; gzip_comp_level 6; gzip_types text/plain text/css application/javascript application/json image/svgxml;配置完成后reload用这个命令验证gzip是否生效curl -H Accept-Encoding: gzip -I http://你的域名/响应头里出现Content-Encoding: gzip就说明压缩已经生效。这一步做完页面的首次加载时间几乎能减掉一半以上是性价比最高的性能优化手段。5. 前后端联调Nginx反向代理、WebSocket与视频流前端静态页面跑通只是第一步。真实项目一定涉及接口请求而前后端分离架构下接口跨域是上线时必踩的坑。这一节我把生产环境接口联调的几种方案讲清楚顺便讲讲WebSocket和m3u8视频流怎么走代理。5.1 开发时proxy与生产环境的差异本地开发时webpack devServer的proxy配置只是把“/api开头的请求转发到后端”这件事限定在本地开发服务器里。build之后的静态文件没有这个代理能力浏览器发出的/api请求直接打到你的域名上如果Nginx没有对应转发规则Nginx会在站点根目录找/api这个文件当然是404或者返回index.html。这就是“本地接口通线上必挂”的根源。解决思路有两条一是后端开启CORS允许前端域名跨域访问二是用Nginx反向代理把/api请求转发给真实后端服务。两条都可行但我的推荐是方案二这样后端服务可以完全不出现在公网前端冷启动也不需要依赖后端修改配置两边解耦更彻底。5.2 用Nginx /api反向代理后端在server块里加入下面这段location /api/ { proxy_pass http://127.0.0.1:8080/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_read_timeout 60s; }这里有个细节特别容易翻车proxy_pass结尾到底带不带斜杠。写成http://127.0.0.1:8080/;客户端请求/api/login会被转发成http://127.0.0.1:8080/login前缀/api被去掉了。写成http://127.0.0.1:8080;不带斜杠客户端请求/api/login会被转发成http://127.0.0.1:8080/api/login路径原样保留。如果你的后端接口路径本身不带/api前缀就用第一种如果后端网关也需要/api前缀来路由就用第二种。这个规则我一开始也常搞混建议你按自己后端真实情况选配完用curl http://你的域名/api/xxx验证一下。5.3 WebSocket的升级与转发配置如果Vue项目用到WebSocket比如聊天、推送、实时进度条代理配置要额外加两行location /ws/ { proxy_pass http://127.0.0.1:9501/; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; }核心在于Upgrade和Connection这两个Header。WebSocket建立连接时浏览器会发送一个协议升级请求Nginx默认的HTTP/1.0代理不支持这个机制必须显式声明proxy_http_version 1.1并把Upgrade和Connection透传给后端否则前端只会看到连接反复断开。前端连接地址也要统一走ws(s)://你的域名/ws不要写内网IP。5.4 补充播放m3u8视频流的代理配置Vue项目里播放m3u8视频流HLS是另一个高频场景。m3u8本质是一个索引文件里面写着一串ts分片地址播放器拿到m3u8后会按分片地址逐个请求视频数据。如果m3u8文件里写的是相对路径/live/segment_001.ts这些分片请求会发到当前域名下你要在Nginx做一层转发指到实际提供视频流的服务或存储location /live/ { proxy_pass http://127.0.0.1:8888/; proxy_set_header Host $host; }前端播放时视频地址就用https://你的域名/live/channel.m3u8。这里有一个很容易被忽略的点如果网站已经开启HTTPSm3u8和ts地址也必须全部走HTTPS否则浏览器会拦截混合内容视频直接黑屏控制台报Mixed Content错误。这个坑我在实际项目中遇到过不止一次排查思路往往要绕很久你先知道这个规律能少走很多弯路。6. 进阶方案用Docker部署Vue项目到阿里云如果你所处的团队对环境一致性要求高或者你希望部署流程能一键搞定、快速回滚那Docker是绕不开的方案。它把构建、运行、依赖全部封装进镜像实现了“在哪跑都一样”的效果。6.1 为什么选择Docker以及适用场景传统部署方式在每台服务器上都要手动安装Nginx、配置路径、拷贝文件一旦要换服务器或者水平扩展整个流程重来一遍还很容易出现“上一个环境能用新环境崩了”的情况。Docker把Nginx版本、配置文件、dist产物全部打进镜像任何装了Docker的服务器都能直接跑环境差异被彻底消解。但Docker也不是银弹如果只是单机部署一个个人Vue项目没有扩容需求传统Nginx部署反而更直观。我的建议是个人小项目用传统方式团队正式项目上Docker两者分开选型。6.2 多阶段构建的Dockerfile写法下面直接给一份生产可用的多阶段Dockerfile# 第一阶段构建vue项目 FROM node:18-alpine AS build WORKDIR /app COPY package*.json ./ RUN npm config set registry https://registry.npmmirror.com RUN npm install COPY . . RUN npm run build # 第二阶段拷贝dist到nginx镜像 FROM nginx:1.25-alpine COPY --frombuild /app/dist /usr/share/nginx/html COPY nginx.conf /etc/nginx/conf.d/default.conf EXPOSE 80 CMD [nginx, -g, daemon off;]对应的nginx.conf注意这是容器内的配置不需要写sites-available那套复杂结构server { listen 80; server_name _; root /usr/share/nginx/html; index index.html; location / { try_files $uri $uri/ /index.html; } location /static/ { expires 30d; add_header Cache-Control public, immutable; } }多阶段构建有个很明显的好处最终镜像里只有Nginx运行环境和dist静态文件没有Node、没有源码、没有node_modules镜像体积能控制在几十MB部署和启动都很快。我见过有人把node环境和源码全打进一个镜像镜像体积几个GB启动还慢完全没有必要。6.3 docker compose管理发布与更新项目根目录创建docker-compose.ymlversion: 3 services: vue-app: build: . image: vue-app:latest ports: - 80:80 restart: always首次构建和启动docker compose build docker compose up -d更新版本时本地改完代码后执行docker compose build --pull docker compose up -d查看日志docker logs -f vue-apprestart: always保证服务器重启后容器自动拉起避免人不在场时服务起不来的问题。我还会在Dockerfile里显式加一行时区配置ENV TZAsia/Shanghai不加的话容器默认UTC时间日志和定时任务的时间会差8个小时排查问题的时候很容易被误导。7. HTTPS与域名绑定线上安全必备到了这一步你的项目已经在IP或域名上跑起来了但还有一个现代Web应用绕不开的问题HTTPS。没有HTTPS浏览器会亮“不安全”的警告很多高级API用不了WebSocket连不上搜索引擎的收录权重也会受影响。所以我强烈建议所有部署到云服务器的Vue项目都配上HTTPS。7.1 申请SSL证书的两种方式一种是阿里云上的免费SSL证书。登录阿里云控制台搜索“数字证书管理服务”申请免费证书填写域名并完成DNS验证后大约几分钟就能签发有效期通常为一年。证书签发后下载Nginx版本的证书文件里面包含.pem和.key两个文件。另一种是Let’s Encrypt的免费证书配合acme.sh自动续期适合不想每年手动操作的人。个人项目用阿里云免费证书体验更简单跟着控制台点就行。7.2 配置Nginx的HTTPS server块把下载好的证书上传到服务器的/etc/nginx/ssl/目录sudo mkdir -p /etc/nginx/ssl然后修改站点配置文件增加443监听server { listen 443 ssl; server_name www.example.com example.com; ssl_certificate /etc/nginx/ssl/example.com.pem; ssl_certificate_key /etc/nginx/ssl/example.com.key; ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers HIGH:!aNULL:!MD5; root /var/www/vue-app; index index.html; location / { try_files $uri $uri/ /index.html; } } # HTTP强制跳转HTTPS server { listen 80; server_name www.example.com example.com; return 301 https://$host$request_uri; }ssl_protocols建议至少TLSv1.2TLSv1.0和1.1因为安全性问题早就被主流浏览器弃用了。HTTP跳转用301这样用户访问http地址时会自动跳到https体验不中断。7.3 HTTPS对Vue项目的影响这里我想展开说一个特别容易踩的盲区HTTPS站点里千万不要夹杂HTTP的资源请求。比如你后端接口用的是http://图片用http://m3u8视频用http://浏览器都会拦截掉页面看起来像坏了。控制台会出现Mixed Content的报错这个坑的排查成本相当高。如果Vue项目用到了WebSocket连接地址也必须从ws://改成wss://否则在HTTPS页面下同样会被阻止。所以你在接入第三方服务和后端接口时要统一确认它们有没有支持HTTPS如果有任何一个不支持就要提前做兼容方案比如通过Nginx再代理一层把外部HTTP服务间接变成同源的HTTPS请求。8. 部署遇到过的坑常见问题与排查实录最后一章我把这些年部署Vue项目踩过的坑整理成速查表再挑几个“高频雷区”展开讲讲方便你对症下药。现象可能原因解决办法页面白屏静态资源路径错误、dist上传不完整看Console报错和Network检查publicPath刷新后404未配置try_filesNginx加try_files $uri $uri/ /index.html;样式异常、图标不显示字体/图片静态资源404检查assetsDir、publicPath、资源是否完整上传接口请求404Nginx反向代理路径错误核对proxy_pass末尾是否带斜杠接口跨域后端未配置CORS或代理未生效优先用Nginx /api反向代理端口访问不通安全组未放行、防火墙拦截检查阿里云安全组和系统ufw/iptables502 Bad Gateway后端服务未启动或代理端口错误检查后端进程、端口、Nginx error.log用户一直看到旧版本浏览器缓存了无hash的index.htmlhtml配no-cache静态资源长缓存8.1 白屏问题第一步永远是看Console和Network白屏是Vue部署中出现频率最高的问题排查顺序我建议固定下来先按F12打开Console看有没有报错信息再切到Network刷新页面看js/css状态码是不是200。如果Console里有“Uncaught SyntaxError”或“Unexpected token‘’”大概率是Nginx把JS文件当文本返回了也就是请求路径错误服务器返回了index.html而不是真正的js文件。这时重点检查publicPath配置和文件是否真的在对应路径。如果Console提示“ChunkLoadError”或者404说明分包文件没找到。这种情况先确认dist是否完整上传再看静态资源路径是否和assetsDir一致。我教徒弟的笨办法是在浏览器地址栏直接访问https://你的域名/static/js/xxx.js能直接看到js内容说明路径没问题返回HTML说明路径层级错了。8.2 路由刷新404try_files的正确打开方式这个问题我在前面讲过这里再补充一个典型场景有些开发者把try_files写在了location /static/里或者压根没写。刷新404其实是Nginx在报真的404因为服务器上没有/home这个文件。修改配置加一行location / { try_files $uri $uri/ /index.html; }改完记得nginx -t systemctl reload nginx不要光改不生效以为配错了。8.3 上传后页面还是旧版本缓存问题这个问题容易被误解成“没部署成功”其实是浏览器把没有hash变化的index.html缓存住了。只要你给index.html设置了Cache-Control: no-cache给带hash的js/css设置了长缓存这个问题基本能根除。如果用户仍然反馈看到旧版本可以在构建后给index.html文件名也加hash或者让部署脚本在发布时先清CDN缓存这是大型项目比较规范的做法。8.4 接口跨域报错先确认是预检失败还是代理没生效浏览器报跨域时我习惯先看请求发出去没有。Network里看不到这个请求说明根本没到达后端问题在前端或代理能看到请求、看到响应但被浏览器拦截报Access-Control-Allow-Origin那才是真正的跨域问题。走Nginx反向代理的项目通常不会出现第二种情况因为浏览器访问的是同源地址。如果后端选择用CORS方案就要保证后端对OPTIONS预检请求正确处理否则跨域是必然的。8.5 端口不通先安全组再防火墙最后Nginx按这个顺序排查能少走很多冤枉路先在阿里云控制台确认安全组放行了80/443端口再在服务器执行sudo ufw status确认系统防火墙没拦住最后systemctl status nginx确认Nginx进程活着。很多人急着检查Nginx配置结果问题出在最前面的安全组这就很浪费时间了。另外Nginx只监听IPv4的话有些云环境IPv6访问会失败可以在配置里加listen [::]:80;同时监听IPv6这类问题比较隐蔽遇到“为什么手机能访问电脑不能”的情况值得怀疑一下这个点。8.6 一个隐藏坑“vue打包后布局异常”的元凶热搜词里有个“vue打包后布局异常”我实际排查过几个案例发现大部分原因根本不是代码逻辑而是静态资源路径出错导致CSS或字体加载不全呈现出来的效果就是“布局乱了”。比如Element Plus的图标字体、某些背景图在本地开发用的是绝对路径打包后publicPath没配好线上加载404图标消失后某些组件的宽度高度就跟着变形。遇到“布局乱了”这种问题我的建议是先看Network里有没有404的字体或图片排查完资源路径再看代码。有时候不是什么复杂bug就是一个路径问题。结尾部署过几个项目之后我的体会越来越深Vue部署本身不复杂难的是让整个发布流程稳定、可重复、不依赖某一个人。所以我最后分享一个小习惯——写一个部署脚本把打包、上传、reload串起来。我自己的deploy.sh长这样#!/bin/bash npm run build rsync -av --delete ./dist/ root你的服务器IP:/var/www/vue-app/ ssh root你的服务器IP nginx -t systemctl reload nginx有了这个脚本以后发布就一行bash deploy.sh不用再复制命令。如果是Docker方案就把中间那段换成docker compose build docker compose up -d思路是一样的。以前我手动敲命令部署每次都要提心吊胆生怕漏了什么现在流程固定下来上线变成一件很自然的事。希望这篇能帮你把Vue项目稳稳地跑在阿里云上。如果你在部署过程里遇到什么奇怪的坑欢迎按我前面说的排查思路走一遍大多数问题都能在Network和日志里找到答案。