从本地跑通到公网访问前后端项目部署实战我把一个前后端分离项目从本地IDE里点一下就能跑折腾到公网HTTPS域名随时可访问前前后后花了整整两个通宵。这个过程中踩的坑、查的资料、试过的方案如果当时有人帮我整理成一条清晰的路线至少能省一半时间。这篇文章就是那条路线的完整复刻。我用的是最常见的组合后端Spring Boot、前端Vue、服务器CentOS部署工具从裸机命令到Nginx、systemd、Docker、宝塔面板全都过了一遍。你可以把这个当成一份超级详细的部署手册也可以当踩坑清单用。不管你是刚学完前后端分离、第一次买服务器还是在公司要独立负责项目上线这文章都适合。先明确一件事部署不是把代码复制到服务器这么简单。它涉及环境差异、网络链路、进程守护、反向代理、防火墙规则、数据库访问这些环环相扣的环节。任何一个环节断了页面都打不开。咱们一个环节一个环节来。1. 部署前必须想清楚的三件事环境、方案、网络链路很多人栽跟头不是栽在操作上而是栽在没想清楚就动手。部署前我会先逼自己回答三个问题服务器上跑什么系统用什么方案部署请求从浏览器到服务器到底走了哪条路1.1 服务器选型和基础环境选服务器这件事别一味图便宜也别盲目上高配。我个人测试过一个常规的前后端分离项目Vue前端 Spring Boot后端 MySQL2核4G的云服务器完全够用并发量不大的话跑起来很稳。1核2G跑MySQL加Java后端会比较吃力内存动不动就飙到80%以上排查起来很麻烦。操作系统选CentOS 7.9或者Ubuntu 20.04都行本文以CentOS为例但命令在Ubuntu上差异不大apt换成yum就能对上。买完服务器第一件事不是连上去装环境而是去云控制台把安全组的入方向规则看清楚。默认情况下80、443端口很可能没开就算你在服务器内部把服务起得再好公网也访问不到。这一步单独拎出来说是因为后文端口不通的问题有相当一部分是这里引起的不是服务本身的问题。1.2 四种部署方案的对比和选型同一套前后端代码上生产的姿势可以完全不同。我自己试过四种各有优劣方案上手难度维护成本适合场景我这边的结论裸机部署命令装JDK、Node、Nginx中中单台服务器、想搞清原理第一次部署强烈建议走一遍宝塔面板低低个人项目、快速上线后期改配置很方便但不适合深究原理Docker Compose中高低多服务编排、环境隔离学会后回不去裸机了Jenkins / Git WebHook自动化高中团队频繁发版第6章单独讲我的建议很直接第一次部署老老实实走一遍裸机命令。因为只有亲手敲过java -jar、配过Nginx你才能理解后面所有工具到底帮你封装了什么。等踩过一轮坑再上宝塔或Docker你会觉得特别顺手。反过来一上来就套宝塔出了问题根本不知道去哪里看日志。1.3 公网请求链路拆解理解部署的本质其实就一句话把原本在本机跑的服务挪到一台24小时开机的机器上并且让外网用户能通过一个固定的入口访问到这些服务。完整的链路是这样的浏览器输入域名 → DNS解析出服务器IP → 请求到达服务器80/443端口 → Nginx收到请求 → 静态资源HTML/CSS/JS直接返回 → /api/ 开头的动态请求反向代理到 Spring Boot8080 → Spring Boot 访问 MySQL 数据库 → 数据原路返回这条链路里最容易出问题的三个节点是Nginx到后端的代理配置、后端到数据库的连接配置、防火墙/安全组对端口的放行。这正好对应了后文的三大部分前端部署、后端部署、网络配置。想明白这条链路之后我部署的时候心里就一直绷着一根弦每个命令、每段配置到底是在这条链路的哪个环节生效2. 后端Spring Boot从本地到服务器的完整过程后端是整个项目的数据大脑。Spring Boot项目在本地跑的时候IDE帮你做了很多隐藏的事比如自动读取application.yml、内嵌Tomcat直接启动、连的是本机数据库。放到Linux服务器上这些默认值全都变成了一颗颗雷。2.1 打包前的配置变形记本地与生产环境的差异我把本地跑通的项目直接mvn package丢到服务器上启动起来确实没报错但接口一调就连接超时。查了一圈才发现配置里连的还是localhost:3306。这在服务器上等于连自己而服务器上根本没装MySQL。正确做法是准备多套环境的配置文件。Spring Boot原生支持application-dev.yml开发环境和application-prod.yml生产环境主配置里只留公共部分通过参数切换。application-prod.yml里必须改的几项spring: datasource: url: jdbc:mysql://你的服务器内网IP或公网IP:3306/数据库名?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai username: 你的数据库用户 password: 你的数据库密码 redis: host: 服务器内网IP port: 6379 password: 你的redis密码 server: port: 8080这里有几个细节很容易踩serverTimezoneAsia/Shanghai 不能省。不加的话日期字段查出来可能比北京时间少8个小时。这个问题在本地偶尔不出现IDE连的MySQL驱动版本不同但一到服务器平台很容易翻车。useSSLfalse 建议加上。很多云数据库默认要求SSL但自签名证书会让Java直接报错。本地开发大家往往没注意线上加这个参数省心。数据库账号不要用root。我吃过这个亏后面讲安全的时候细说。至少创建一个只操作当前库的账号。主配置application.yml里再指定激活哪个环境spring: profiles: active: prod打包完启动时也可以用命令强制指定环境比如java -jar app.jar --spring.profiles.activeprod这样即使配置文件写错了也有机会临时纠正。2.2 Maven打包skipTests和profile本地开发用IDE敲个绿色三角形就启动了这不算生产构建。生产构建要在项目根目录执行mvn clean package -DskipTests-DskipTests有两个含义我这里解释一下。不加这个参数Maven会跑一遍单元测试如果你们项目测试类里写了连数据库或Redis的用例构建阶段直接失败。不是说不让你跑测试而是服务器打包这个环节通常没有完整的测试环境先跳过、把包打出来才是首要目标。CI/CD里面再单独跑测试不迟。打包完成后target目录下会生成一个xxx.jar。我习惯把jar包手动重命名成app.jar这样后面所有的启动命令、systemd配置、脚本都不用频繁改版本号。2.3 JDK安装与Java进程启动服务器上装JDK我踩过一个经典的坑用yum install java默认装的是OpenJDK 1.8但项目用的某些依赖是拿JDK 11编译的一启动就报UnsupportedClassVersionError。这个错字面意思很明确类文件版本号比JVM能支持的更高。先看项目用的Java版本java -version如果版本对不上装对应版本。CentOS上用yum装指定版本比较麻烦我是直接下载官方tar包解压配置的# 下载 JDK 11 的 tar 包64位Linux版 tar -zxvf jdk-11.0.20_linux-x64_bin.tar.gz mv jdk-11.0.20 /usr/local/java然后配置环境变量vim /etc/profile在文件末尾追加export JAVA_HOME/usr/local/java export PATH$JAVA_HOME/bin:$PATH保存后执行source /etc/profile验证一下java -version第一次启动后端时我用的是前台启动java -jar /opt/app/app.jar --spring.profiles.activeprod这样能看到日志直接滚出来便于确认启动过程有没有报错。等确认没问题了再切到systemd守护进程下一步。2.4 用systemd守护进程服务崩溃自动拉起裸机用java -jar启动有个致命问题终端一关进程就没了。加nohup能顶一阵但进程崩溃了不会自动恢复服务器重启后也不会自动启动。我在第N次手动重启后端之后终于老实用了systemd。在/etc/systemd/system/下创建app.service文件[Unit] DescriptionMy Spring Boot Application Afternetwork.target mysqld.service [Service] Typesimple Userroot WorkingDirectory/opt/app ExecStart/usr/local/java/bin/java -jar /opt/app/app.jar --spring.profiles.activeprod Restarton-failure RestartSec10 StandardOutputjournal StandardErrorjournal [Install] WantedBymulti-user.target然后启动并设为开机自启systemctl daemon-reload systemctl start app systemctl enable app查看运行状态systemctl status app查看实时日志注意是journalctl -u appjournalctl -u app -f这段配置里Restarton-failure和RestartSec10是我最看重的两行。它意味着进程异常退出后10秒自动拉起。有了这行半夜项目因为内存问题崩了它会自己活过来不用我们爬起来手动java -jar。这个收益在第一天部署后第二天早上醒来发现服务自己恢复了的时候会特别有体会。3. 前端Vue项目从build到Nginx托管坑几乎全在这一步前端部署的核心不是把文件拷到服务器而是先构建成纯静态资源HTML/JS/CSS再用一个Web服务器托管。Vue项目开发时的npm run dev是开发服务器带热更新的绝不能直接部署。3.1 打包前端vite.config.js里的base路径前端项目执行构建npm run build构建产物默认在dist目录。这一步在本地能成功到服务器上不一定能正常访问最大的坑是资源路径问题。如果你的前端部署在域名根路径比如https://example.com那vite.config.js里的base用默认的/问题不大。但如果你打算把前端放在子路径比如https://example.com/admin/那必须设置// vite.config.js export default defineConfig({ base: /admin/, plugins: [vue()] })这个base值会直接影响打包出来的HTML里script src/admin/assets/xxx.js的路径。不设对的话浏览器会去根路径找JS文件结果404页面白屏。另外提醒一点构建产物的体积。如果dist目录特别大问题出在默认打包了sourcemap。强行关掉build: { sourcemap: false, chunkSizeWarningLimit: 1500 }3.2 Nginx安装和静态资源托管Nginx是部署前端最主流的方案。我见过有人用Tomcat直接部署前端dist目录也能跑但Nginx的静态资源处理能力更强、配置更灵活尤其是后面做反向代理时是绕不开的。安装yum install nginx -y配置默认站点vim /etc/nginx/conf.d/default.conf一个最基础的静态托管配置server { listen 80; server_name your-domain.com; root /opt/frontend/dist; index index.html; location / { try_files $uri $uri/ /index.html; } }解释几个关键点root指向dist目录注意是文件系统路径不是URL路径。try_files $uri $uri/ /index.html这行是Vue Router history模式的生命线。如果不加访问https://your-domain.com/about时Nginx会在文件系统里找about文件找不到就直接404但首页却好好的。加了之后所有不存在的路径都回退到index.html由前端路由接管。把构建好的文件传到服务器。我用的是最朴素的办法scp -r dist/* root服务器IP:/opt/frontend/dist/3.3 为什么前端部署首选Nginx而不是Tomcat这个问题我被人问过很多次。Tomcat当然能托管静态页面但术业有专攻Nginx对静态文件的并发处理能力远强于Tomcat。它采用事件驱动模型一个worker能扛上万并发连接Tomcat是线程池模型每个请求占一个线程资源消耗大。Nginx后面做反向代理非常自然。前端静态资源由Nginx直接返回/api/的请求转发给Java后端一个端口80搞定所有事情。如果要走Tomcat托管前端还得再带一个Tomcat处理动态请求端口规划就很别扭。Nginx配置修改后nginx -s reload秒级生效不用重启Java进程。3.4 端口设计和防火墙细节后端默认跑在8080前端Nginx跑在80。公网用户只需要访问80后端端口8080完全可以不对公网开放。这个设计是安全的关键。我用的是最简单也最严的边界方案安全组/防火墙只放行 80、443、22SSH。Nginx监听80HTTP和443HTTPS。后端8080只允许本机访问或者只允许Nginx所在网段访问。服务器内部防火墙firewalld的命令systemctl start firewalld firewall-cmd --permanent --add-port80/tcp firewall-cmd --permanent --add-port443/tcp firewall-cmd --permanent --add-servicehttp firewall-cmd --permanent --add-servicehttps firewall-cmd --reload注意如果上面命令执行后公网仍然访问不了80先停掉firewalld试试systemctl stop firewalld如果停掉后能访问了说明是防火墙规则问题如果停掉还不行那就是云服务商的安全组没放行。两条线都要查这事我干过不止一次。4. 公网访问的核心域名、反向代理与HTTPS前端能通过IP访问、后端接口也能本机调通这只能算局域网部署。公网用户要体面地访问还差三件事域名解析、反向代理、HTTPS证书。这一章是内网跑通和公网访问之间的分水岭。4.1 反向代理的逻辑为什么80端口只能有一个主人服务器上已经有Nginx占用了80端口但后端Java占用了8080。问题是公网用户浏览器默认只访问80端口谁去把80端口的请求转给8080答案就是Nginx反向代理。它的意思是Nginx在80端口当门卫收到请求后按规则分发给不同的办公室后端服务。这不光是为了省端口更是为了统一入口、隐藏后端结构、方便加HTTPS。Nginx配置反向代理的完整样子server { listen 80; server_name your-domain.com; # 前端静态资源 root /opt/frontend/dist; index index.html; # 前端路由History模式回退 location / { try_files $uri $uri/ /index.html; } # 后端接口反向代理 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_pass http://127.0.0.1:8080;的写法。如果写成http://127.0.0.1:8080/带斜杠请求/api/login会被转发成/login前缀/api被剥掉如果像我这样不带斜杠转发过去还是/api/login。这个细节决定了后端接口路径要不要带/api。我的后端Controller里没写/api统一前缀所以Nginx这边不带斜杠保持路径原样转发。第二个是location /api/的匹配优先级。Nginx匹配location的规则是精确匹配优先于前缀匹配^~优先于正则匹配~然后才是普通前缀匹配。而多个普通前缀匹配里最长前缀优先。所以/api/login会命中/api/而不是/,这正好满足需求。第三个是安全组的配合。后端8080不对公网开放只有Nginx在80端口对公网服务。公网用户即使扫到8080端口也只会看到连接失败而不是直接暴露Spring Boot接口。4.2 Vue前端请求地址到底该怎么保持灵活前端代码里axios.defaults.baseURL这个配置是本地跑通后部署到线上很容易忘改的。很多人写死http://localhost:8080部署后页面能打开接口全是404或CORS错误。正确做法是分环境配置。Vue项目一般在项目根目录建两个环境文件.env.developmentVITE_API_BASE_URL/api.env.productionVITE_API_BASE_URL/api然后在代码里用// main.js 或 request.js axios.defaults.baseURL import.meta.env.VITE_API_BASE_URL注意我把开发和生产都配成了/api但含义不同开发环境Vite开发服务器会把/api代理到http://localhost:8080配置在vite.config.js的server.proxy。生产环境Nginx会把/api反向代理到http://127.0.0.1:8080。这样前端代码里就没有任何硬编码的服务器地址环境切换时只改部署配置不用动代码。这是前后端分离项目部署的一种非常舒服的姿势。4.3 HTTPS证书部署的最后一块拼图没有HTTPS现代浏览器会直接提示不安全而且很多浏览器功能比如摄像头、地理定位在非HTTPS环境下会受限。我建议域名备案完、解析生效后立刻加HTTPS。云厂商一般提供免费SSL证书申请申请下来会有两个文件.pem证书和.key私钥。放到服务器mkdir -p /etc/nginx/ssl # 上传证书和私钥到这个目录Nginx配置443端口server { listen 443 ssl; server_name your-domain.com; ssl_certificate /etc/nginx/ssl/your-domain.com.pem; ssl_certificate_key /etc/nginx/ssl/your-domain.com.key; root /opt/frontend/dist; index index.html; location / { try_files $uri $uri/ /index.html; } 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; } } # HTTP 强制跳转 HTTPS server { listen 80; server_name your-domain.com; return 301 https://$host$request_uri; }配置完执行nginx -t nginx -s reloadnginx -t是检查配置语法有问题它会直接告诉你第几行出错。所有Nginx配置修改后先nginx -t再reload这个习惯让我少拉了很多次配置改坏了导致站点全挂的紧急会议。域名解析这一步很简单去你的DNS服务商处加一条A记录把your-domain.com指向服务器公网IP等它生效即可。5. 部署之后的反向排查本地能跑线上崩了问题出在哪前端能打开、后端接口能通、HTTPS证书正常部署似乎圆满了。但生产环境的复杂性往往在上线后第一波真实流量进来时才暴露。这一章整理我实际遇到过的也是社区里最高频的几类线上问题以及对应的排查链路。5.1 502 Bad Gateway先从后端进程查起浏览器里刷出502 Bad Gateway说明Nginx在80端口活着但它往8080转发请求时没有得到有效的HTTP响应。完整的排查链路看后端进程是否存活systemctl status app如果进程挂了RestartSec会自动拉起但反复拉起又反复崩溃说明后端本身有致命错误看日志journalctl -u app -n 50直接在服务器本机测试后端接口curl http://127.0.0.1:8080/api/health这个命令等效于Nginx转发请求时后端的处理情况。如果这里都不通问题锁定在后端进程或服务端口如果这里通问题大概率出在Nginx配置。检查Nginx的错误日志tail -n 50 /var/log/nginx/error.log我遇到过一次诡异的502后端进程活着、本机curl通、Nginx配置看起来没问题但就是502。最后是在错误日志里看到connect() failed (111: Connection refused) while connecting to upstream才意识到后端监听的是0.0.0.0:8080但防火墙把本机回环以外的连接拦了。解决方法是给8080加一条firewalld规则只允许来自127.0.0.1的连接firewall-cmd --permanent --add-rich-rulerule familyipv4 source address127.0.0.1 port port8080 protocoltcp accept firewall-cmd --reload5.2 404的两个处境是路由问题还是接口问题404分两种处理方式完全不同页面404访问https://your-domain.com/about直接404。几乎可以断定是try_files没配置。在location /里加上那一行回退配置reload Nginx即可。接口404页面正常但某个接口调用返回404。先分清是Nginx层404还是后端404# 看本机curl后端接口 curl -v http://127.0.0.1:8080/api/login如果本机curl能通但浏览器不通把浏览器Network面板里那个接口的请求URL和后端Controller的RequestMapping值对一下大概率是前缀问题。我遇到一次的是后端接口路径是/user/login但Nginx配置用了带斜杠的proxy_pass http://127.0.0.1:8080/请求转发后被剥成了/login于是404。去掉Nginx代理地址末尾的斜杠就解决了。5.3 数据库连接失败和时间时区问题后端能启动、前台页面正常但一登录就报数据库错误这类问题在本地几乎不会出现因为本地数据库就在本机。上了服务器数据库连接失败最常见三种MySQL没开机自启。服务器重启后MySQL没起来Java进程在Spring Boot启动时连接失败导致整个应用起不来。解决方案是设置开机自启systemctl enable mysqld密码或账号不对。这里提醒一个坑MySQL 8.0默认的加密方式可能是caching_sha2_password老版本的Java驱动不认识会报Public Key Retrieval is not allowed。解决方案有两个换mysql-connector-java8.0以上的驱动版本或者在连接串里加allowPublicKeyRetrievaltrueuseSSLfalse。数据库时区问题。接口查出来的时间比实际时间早8小时这是老问题了。除了在连接串里加serverTimezoneAsia/Shanghai还建议把MySQL的时区也改掉vim /etc/my.cnf # 在 [mysqld] 下加 default-time-zone08:00顺便说个细节MySQL跑在服务器上连接串建议用内网IP而不是公网IP。因为公网IP绕了一圈可能走了云厂商的NAT网关或防火墙延迟高还可能被云安全策略拦截。同一台服务器内部互访用内网IP甚至127.0.0.1都行。5.4 前端CSS/JS加载404页面空白F12看到一堆JS/CSS文件404。这个问题在上线时特别常见原因有两个base路径不对。如果项目部署在子路径但vite.config.js里的base没改资源路径会指向根路径。改完重新npm run build。前端资源没更新。重新构建后的dist没有完整覆盖服务器上的旧文件。我建议每次部署前先删掉旧目录再传新的rm -rf /opt/frontend/dist/*5.5 排查逻辑先看网络再看进程最后看配置踩过这么多坑我总结出一个固定排查顺序按照这个顺序来不会乱网络层本机curl -I http://127.0.0.1:80通不通公网机器curl -I http://服务器IP通不通不通就查安全组和防火墙。进程层Nginx、后端Java进程、MySQL进程是否都在systemctl status逐个查。配置层Nginx配置语法、前端资源路径、后端环境配置逐个对。数据层数据库是否能连表结构是否完整种子数据是否导入大多数问题在第二步和第三步之间就能找到答案。养成按层排查的习惯就不至于东一榔头西一棒子地瞎试。6. 进阶玩法Docker化部署与自动化发版如果项目要长期维护、频繁发版再手动敲命令肯定不是长久之计。上线稳定后我把部署方式升级了一轮用Docker打包运行环境用Git WebHook触发自动化部署。这套组合下来发版从折腾半小时变成push代码就完事。6.1 Docker部署Web项目的完整流程Docker的核心价值是环境一致。本机能跑的镜像到服务器上也是一模一样不存在在我机器上是好的啊这种问题。先装Dockeryum install -y yum-utils yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo yum install -y docker-ce docker-ce-cli containerd.io systemctl start docker systemctl enable docker然后写Dockerfile。后端项目FROM openjdk:11-jre-slim WORKDIR /app COPY app.jar /app/app.jar EXPOSE 8080 ENTRYPOINT [java, -jar, /app/app.jar, --spring.profiles.activeprod]前端项目FROM node:16-alpine AS build WORKDIR /app COPY package*.json ./ RUN npm install COPY . . RUN npm run build FROM nginx: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;]MySQL也放到容器里为了保证数据不丢用Docker数据卷挂载docker volume create mysql-data docker run -d \ --name mysql \ -e MYSQL_ROOT_PASSWORD你的密码 \ -e MYSQL_DATABASE你的库名 \ -v mysql-data:/var/lib/mysql \ -p 3306:3306 \ mysql:8.0但更好的方式是使用docker-compose.yml把三个服务编排起来version: 3.8 services: mysql: image: mysql:8.0 container_name: mysql environment: MYSQL_ROOT_PASSWORD: yourpassword MYSQL_DATABASE: yourdb volumes: - mysql-data:/var/lib/mysql ports: - 3306:3306 restart: always backend: build: ./backend container_name: backend depends_on: - mysql environment: SPRING_PROFILES_ACTIVE: prod SPRING_DATASOURCE_URL: jdbc:mysql://mysql:3306/yourdb?useSSLfalseserverTimezoneAsia/Shanghai ports: - 8080:8080 restart: always frontend: build: ./frontend container_name: frontend depends_on: - backend ports: - 80:80 restart: always volumes: mysql-data:注意后端连接串里的主机名写的是mysql而不是IP。这是Docker Compose内置的DNS服务容器之间可以直接用服务名互联不用关心彼此的IP地址。这套编排的思想是docker-compose up -d一条命令MySQL、后端、前端全部拉起来。docker-compose up -d --build6.2 Git WebHook 宝塔面板实现push代码自动部署Docker解决的是环境一致但发版时还要ssh上去执行命令也很烦。后来我配了Git WebHook 宝塔面板的自动化流程项目push代码后服务器自动拉取、自动构建、自动重启。思路是这样的服务器上装宝塔面板。宝塔的宝塔WebHook插件能生成一个URL这个URL被访问时触发自定义脚本。项目推送代码时在Git仓库的WebHook设置里填上这个URL。服务器收到请求后执行脚本拉取代码 →mvn package或npm run build→ 重启服务。脚本大致这样以Java后端为例#!/bin/bash cd /project/backend git pull origin main mvn clean package -DskipTests systemctl restart app前端同理#!/bin/bash cd /project/frontend git pull origin main npm install npm run build rm -rf /opt/frontend/dist/* cp -r dist/* /opt/frontend/dist/这套跑通之后团队发版只需要git push剩下的交给服务器自己完成。我配的时候还踩过一个坑Git仓库拉取需要凭据建议用Deploy KeySSH Key方式而不是每次都输用户名密码否则自动化脚本会因为权限问题卡在git pull那一步。6.3 我的最终建议什么规模用什么方案这三种方式没有优劣之分只有合不合适个人学习项目、日PV几千的小站宝塔面板最舒服。图形化界面管理Nginx、MySQL部署快还有自动备份功能。因为你不需要关心集群、编排这些问题。正规商业项目、需要快速交付Docker Compose是性价比最高的方案。环境一致、便于回滚换镜像tag就行、扩展方便。团队项目、发版频繁Git WebHook或Jenkins自动化是解放生产力的关键。我用的Git WebHook方案轻量够用更大团队可以上Jenkins支持流水线、测试报告、多环境发布。我个人实践下来的心得是先手动部署通一遍再用Docker固化环境最后加自动化提升效率这个顺序踩坑最少。一上来就追新技术方案很容易在部署和工具本身的使用两座大山之间迷失方向。如果你现在正卡在本地跑通但线上打不开按这篇文章的链路从头对一遍后端进程起来了吗、数据库连上了吗、Nginx代理配全了吗、防火墙端口开了吗、前端路径对吗。99%的问题都能在链路上找到答案。剩下的1%重启大法偶尔也管用但记得先找到根因再重启否则它还会再回来找你。
前后端项目部署实战：从本地跑通到公网HTTPS访问
从本地跑通到公网访问前后端项目部署实战我把一个前后端分离项目从本地IDE里点一下就能跑折腾到公网HTTPS域名随时可访问前前后后花了整整两个通宵。这个过程中踩的坑、查的资料、试过的方案如果当时有人帮我整理成一条清晰的路线至少能省一半时间。这篇文章就是那条路线的完整复刻。我用的是最常见的组合后端Spring Boot、前端Vue、服务器CentOS部署工具从裸机命令到Nginx、systemd、Docker、宝塔面板全都过了一遍。你可以把这个当成一份超级详细的部署手册也可以当踩坑清单用。不管你是刚学完前后端分离、第一次买服务器还是在公司要独立负责项目上线这文章都适合。先明确一件事部署不是把代码复制到服务器这么简单。它涉及环境差异、网络链路、进程守护、反向代理、防火墙规则、数据库访问这些环环相扣的环节。任何一个环节断了页面都打不开。咱们一个环节一个环节来。1. 部署前必须想清楚的三件事环境、方案、网络链路很多人栽跟头不是栽在操作上而是栽在没想清楚就动手。部署前我会先逼自己回答三个问题服务器上跑什么系统用什么方案部署请求从浏览器到服务器到底走了哪条路1.1 服务器选型和基础环境选服务器这件事别一味图便宜也别盲目上高配。我个人测试过一个常规的前后端分离项目Vue前端 Spring Boot后端 MySQL2核4G的云服务器完全够用并发量不大的话跑起来很稳。1核2G跑MySQL加Java后端会比较吃力内存动不动就飙到80%以上排查起来很麻烦。操作系统选CentOS 7.9或者Ubuntu 20.04都行本文以CentOS为例但命令在Ubuntu上差异不大apt换成yum就能对上。买完服务器第一件事不是连上去装环境而是去云控制台把安全组的入方向规则看清楚。默认情况下80、443端口很可能没开就算你在服务器内部把服务起得再好公网也访问不到。这一步单独拎出来说是因为后文端口不通的问题有相当一部分是这里引起的不是服务本身的问题。1.2 四种部署方案的对比和选型同一套前后端代码上生产的姿势可以完全不同。我自己试过四种各有优劣方案上手难度维护成本适合场景我这边的结论裸机部署命令装JDK、Node、Nginx中中单台服务器、想搞清原理第一次部署强烈建议走一遍宝塔面板低低个人项目、快速上线后期改配置很方便但不适合深究原理Docker Compose中高低多服务编排、环境隔离学会后回不去裸机了Jenkins / Git WebHook自动化高中团队频繁发版第6章单独讲我的建议很直接第一次部署老老实实走一遍裸机命令。因为只有亲手敲过java -jar、配过Nginx你才能理解后面所有工具到底帮你封装了什么。等踩过一轮坑再上宝塔或Docker你会觉得特别顺手。反过来一上来就套宝塔出了问题根本不知道去哪里看日志。1.3 公网请求链路拆解理解部署的本质其实就一句话把原本在本机跑的服务挪到一台24小时开机的机器上并且让外网用户能通过一个固定的入口访问到这些服务。完整的链路是这样的浏览器输入域名 → DNS解析出服务器IP → 请求到达服务器80/443端口 → Nginx收到请求 → 静态资源HTML/CSS/JS直接返回 → /api/ 开头的动态请求反向代理到 Spring Boot8080 → Spring Boot 访问 MySQL 数据库 → 数据原路返回这条链路里最容易出问题的三个节点是Nginx到后端的代理配置、后端到数据库的连接配置、防火墙/安全组对端口的放行。这正好对应了后文的三大部分前端部署、后端部署、网络配置。想明白这条链路之后我部署的时候心里就一直绷着一根弦每个命令、每段配置到底是在这条链路的哪个环节生效2. 后端Spring Boot从本地到服务器的完整过程后端是整个项目的数据大脑。Spring Boot项目在本地跑的时候IDE帮你做了很多隐藏的事比如自动读取application.yml、内嵌Tomcat直接启动、连的是本机数据库。放到Linux服务器上这些默认值全都变成了一颗颗雷。2.1 打包前的配置变形记本地与生产环境的差异我把本地跑通的项目直接mvn package丢到服务器上启动起来确实没报错但接口一调就连接超时。查了一圈才发现配置里连的还是localhost:3306。这在服务器上等于连自己而服务器上根本没装MySQL。正确做法是准备多套环境的配置文件。Spring Boot原生支持application-dev.yml开发环境和application-prod.yml生产环境主配置里只留公共部分通过参数切换。application-prod.yml里必须改的几项spring: datasource: url: jdbc:mysql://你的服务器内网IP或公网IP:3306/数据库名?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai username: 你的数据库用户 password: 你的数据库密码 redis: host: 服务器内网IP port: 6379 password: 你的redis密码 server: port: 8080这里有几个细节很容易踩serverTimezoneAsia/Shanghai 不能省。不加的话日期字段查出来可能比北京时间少8个小时。这个问题在本地偶尔不出现IDE连的MySQL驱动版本不同但一到服务器平台很容易翻车。useSSLfalse 建议加上。很多云数据库默认要求SSL但自签名证书会让Java直接报错。本地开发大家往往没注意线上加这个参数省心。数据库账号不要用root。我吃过这个亏后面讲安全的时候细说。至少创建一个只操作当前库的账号。主配置application.yml里再指定激活哪个环境spring: profiles: active: prod打包完启动时也可以用命令强制指定环境比如java -jar app.jar --spring.profiles.activeprod这样即使配置文件写错了也有机会临时纠正。2.2 Maven打包skipTests和profile本地开发用IDE敲个绿色三角形就启动了这不算生产构建。生产构建要在项目根目录执行mvn clean package -DskipTests-DskipTests有两个含义我这里解释一下。不加这个参数Maven会跑一遍单元测试如果你们项目测试类里写了连数据库或Redis的用例构建阶段直接失败。不是说不让你跑测试而是服务器打包这个环节通常没有完整的测试环境先跳过、把包打出来才是首要目标。CI/CD里面再单独跑测试不迟。打包完成后target目录下会生成一个xxx.jar。我习惯把jar包手动重命名成app.jar这样后面所有的启动命令、systemd配置、脚本都不用频繁改版本号。2.3 JDK安装与Java进程启动服务器上装JDK我踩过一个经典的坑用yum install java默认装的是OpenJDK 1.8但项目用的某些依赖是拿JDK 11编译的一启动就报UnsupportedClassVersionError。这个错字面意思很明确类文件版本号比JVM能支持的更高。先看项目用的Java版本java -version如果版本对不上装对应版本。CentOS上用yum装指定版本比较麻烦我是直接下载官方tar包解压配置的# 下载 JDK 11 的 tar 包64位Linux版 tar -zxvf jdk-11.0.20_linux-x64_bin.tar.gz mv jdk-11.0.20 /usr/local/java然后配置环境变量vim /etc/profile在文件末尾追加export JAVA_HOME/usr/local/java export PATH$JAVA_HOME/bin:$PATH保存后执行source /etc/profile验证一下java -version第一次启动后端时我用的是前台启动java -jar /opt/app/app.jar --spring.profiles.activeprod这样能看到日志直接滚出来便于确认启动过程有没有报错。等确认没问题了再切到systemd守护进程下一步。2.4 用systemd守护进程服务崩溃自动拉起裸机用java -jar启动有个致命问题终端一关进程就没了。加nohup能顶一阵但进程崩溃了不会自动恢复服务器重启后也不会自动启动。我在第N次手动重启后端之后终于老实用了systemd。在/etc/systemd/system/下创建app.service文件[Unit] DescriptionMy Spring Boot Application Afternetwork.target mysqld.service [Service] Typesimple Userroot WorkingDirectory/opt/app ExecStart/usr/local/java/bin/java -jar /opt/app/app.jar --spring.profiles.activeprod Restarton-failure RestartSec10 StandardOutputjournal StandardErrorjournal [Install] WantedBymulti-user.target然后启动并设为开机自启systemctl daemon-reload systemctl start app systemctl enable app查看运行状态systemctl status app查看实时日志注意是journalctl -u appjournalctl -u app -f这段配置里Restarton-failure和RestartSec10是我最看重的两行。它意味着进程异常退出后10秒自动拉起。有了这行半夜项目因为内存问题崩了它会自己活过来不用我们爬起来手动java -jar。这个收益在第一天部署后第二天早上醒来发现服务自己恢复了的时候会特别有体会。3. 前端Vue项目从build到Nginx托管坑几乎全在这一步前端部署的核心不是把文件拷到服务器而是先构建成纯静态资源HTML/JS/CSS再用一个Web服务器托管。Vue项目开发时的npm run dev是开发服务器带热更新的绝不能直接部署。3.1 打包前端vite.config.js里的base路径前端项目执行构建npm run build构建产物默认在dist目录。这一步在本地能成功到服务器上不一定能正常访问最大的坑是资源路径问题。如果你的前端部署在域名根路径比如https://example.com那vite.config.js里的base用默认的/问题不大。但如果你打算把前端放在子路径比如https://example.com/admin/那必须设置// vite.config.js export default defineConfig({ base: /admin/, plugins: [vue()] })这个base值会直接影响打包出来的HTML里script src/admin/assets/xxx.js的路径。不设对的话浏览器会去根路径找JS文件结果404页面白屏。另外提醒一点构建产物的体积。如果dist目录特别大问题出在默认打包了sourcemap。强行关掉build: { sourcemap: false, chunkSizeWarningLimit: 1500 }3.2 Nginx安装和静态资源托管Nginx是部署前端最主流的方案。我见过有人用Tomcat直接部署前端dist目录也能跑但Nginx的静态资源处理能力更强、配置更灵活尤其是后面做反向代理时是绕不开的。安装yum install nginx -y配置默认站点vim /etc/nginx/conf.d/default.conf一个最基础的静态托管配置server { listen 80; server_name your-domain.com; root /opt/frontend/dist; index index.html; location / { try_files $uri $uri/ /index.html; } }解释几个关键点root指向dist目录注意是文件系统路径不是URL路径。try_files $uri $uri/ /index.html这行是Vue Router history模式的生命线。如果不加访问https://your-domain.com/about时Nginx会在文件系统里找about文件找不到就直接404但首页却好好的。加了之后所有不存在的路径都回退到index.html由前端路由接管。把构建好的文件传到服务器。我用的是最朴素的办法scp -r dist/* root服务器IP:/opt/frontend/dist/3.3 为什么前端部署首选Nginx而不是Tomcat这个问题我被人问过很多次。Tomcat当然能托管静态页面但术业有专攻Nginx对静态文件的并发处理能力远强于Tomcat。它采用事件驱动模型一个worker能扛上万并发连接Tomcat是线程池模型每个请求占一个线程资源消耗大。Nginx后面做反向代理非常自然。前端静态资源由Nginx直接返回/api/的请求转发给Java后端一个端口80搞定所有事情。如果要走Tomcat托管前端还得再带一个Tomcat处理动态请求端口规划就很别扭。Nginx配置修改后nginx -s reload秒级生效不用重启Java进程。3.4 端口设计和防火墙细节后端默认跑在8080前端Nginx跑在80。公网用户只需要访问80后端端口8080完全可以不对公网开放。这个设计是安全的关键。我用的是最简单也最严的边界方案安全组/防火墙只放行 80、443、22SSH。Nginx监听80HTTP和443HTTPS。后端8080只允许本机访问或者只允许Nginx所在网段访问。服务器内部防火墙firewalld的命令systemctl start firewalld firewall-cmd --permanent --add-port80/tcp firewall-cmd --permanent --add-port443/tcp firewall-cmd --permanent --add-servicehttp firewall-cmd --permanent --add-servicehttps firewall-cmd --reload注意如果上面命令执行后公网仍然访问不了80先停掉firewalld试试systemctl stop firewalld如果停掉后能访问了说明是防火墙规则问题如果停掉还不行那就是云服务商的安全组没放行。两条线都要查这事我干过不止一次。4. 公网访问的核心域名、反向代理与HTTPS前端能通过IP访问、后端接口也能本机调通这只能算局域网部署。公网用户要体面地访问还差三件事域名解析、反向代理、HTTPS证书。这一章是内网跑通和公网访问之间的分水岭。4.1 反向代理的逻辑为什么80端口只能有一个主人服务器上已经有Nginx占用了80端口但后端Java占用了8080。问题是公网用户浏览器默认只访问80端口谁去把80端口的请求转给8080答案就是Nginx反向代理。它的意思是Nginx在80端口当门卫收到请求后按规则分发给不同的办公室后端服务。这不光是为了省端口更是为了统一入口、隐藏后端结构、方便加HTTPS。Nginx配置反向代理的完整样子server { listen 80; server_name your-domain.com; # 前端静态资源 root /opt/frontend/dist; index index.html; # 前端路由History模式回退 location / { try_files $uri $uri/ /index.html; } # 后端接口反向代理 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_pass http://127.0.0.1:8080;的写法。如果写成http://127.0.0.1:8080/带斜杠请求/api/login会被转发成/login前缀/api被剥掉如果像我这样不带斜杠转发过去还是/api/login。这个细节决定了后端接口路径要不要带/api。我的后端Controller里没写/api统一前缀所以Nginx这边不带斜杠保持路径原样转发。第二个是location /api/的匹配优先级。Nginx匹配location的规则是精确匹配优先于前缀匹配^~优先于正则匹配~然后才是普通前缀匹配。而多个普通前缀匹配里最长前缀优先。所以/api/login会命中/api/而不是/,这正好满足需求。第三个是安全组的配合。后端8080不对公网开放只有Nginx在80端口对公网服务。公网用户即使扫到8080端口也只会看到连接失败而不是直接暴露Spring Boot接口。4.2 Vue前端请求地址到底该怎么保持灵活前端代码里axios.defaults.baseURL这个配置是本地跑通后部署到线上很容易忘改的。很多人写死http://localhost:8080部署后页面能打开接口全是404或CORS错误。正确做法是分环境配置。Vue项目一般在项目根目录建两个环境文件.env.developmentVITE_API_BASE_URL/api.env.productionVITE_API_BASE_URL/api然后在代码里用// main.js 或 request.js axios.defaults.baseURL import.meta.env.VITE_API_BASE_URL注意我把开发和生产都配成了/api但含义不同开发环境Vite开发服务器会把/api代理到http://localhost:8080配置在vite.config.js的server.proxy。生产环境Nginx会把/api反向代理到http://127.0.0.1:8080。这样前端代码里就没有任何硬编码的服务器地址环境切换时只改部署配置不用动代码。这是前后端分离项目部署的一种非常舒服的姿势。4.3 HTTPS证书部署的最后一块拼图没有HTTPS现代浏览器会直接提示不安全而且很多浏览器功能比如摄像头、地理定位在非HTTPS环境下会受限。我建议域名备案完、解析生效后立刻加HTTPS。云厂商一般提供免费SSL证书申请申请下来会有两个文件.pem证书和.key私钥。放到服务器mkdir -p /etc/nginx/ssl # 上传证书和私钥到这个目录Nginx配置443端口server { listen 443 ssl; server_name your-domain.com; ssl_certificate /etc/nginx/ssl/your-domain.com.pem; ssl_certificate_key /etc/nginx/ssl/your-domain.com.key; root /opt/frontend/dist; index index.html; location / { try_files $uri $uri/ /index.html; } 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; } } # HTTP 强制跳转 HTTPS server { listen 80; server_name your-domain.com; return 301 https://$host$request_uri; }配置完执行nginx -t nginx -s reloadnginx -t是检查配置语法有问题它会直接告诉你第几行出错。所有Nginx配置修改后先nginx -t再reload这个习惯让我少拉了很多次配置改坏了导致站点全挂的紧急会议。域名解析这一步很简单去你的DNS服务商处加一条A记录把your-domain.com指向服务器公网IP等它生效即可。5. 部署之后的反向排查本地能跑线上崩了问题出在哪前端能打开、后端接口能通、HTTPS证书正常部署似乎圆满了。但生产环境的复杂性往往在上线后第一波真实流量进来时才暴露。这一章整理我实际遇到过的也是社区里最高频的几类线上问题以及对应的排查链路。5.1 502 Bad Gateway先从后端进程查起浏览器里刷出502 Bad Gateway说明Nginx在80端口活着但它往8080转发请求时没有得到有效的HTTP响应。完整的排查链路看后端进程是否存活systemctl status app如果进程挂了RestartSec会自动拉起但反复拉起又反复崩溃说明后端本身有致命错误看日志journalctl -u app -n 50直接在服务器本机测试后端接口curl http://127.0.0.1:8080/api/health这个命令等效于Nginx转发请求时后端的处理情况。如果这里都不通问题锁定在后端进程或服务端口如果这里通问题大概率出在Nginx配置。检查Nginx的错误日志tail -n 50 /var/log/nginx/error.log我遇到过一次诡异的502后端进程活着、本机curl通、Nginx配置看起来没问题但就是502。最后是在错误日志里看到connect() failed (111: Connection refused) while connecting to upstream才意识到后端监听的是0.0.0.0:8080但防火墙把本机回环以外的连接拦了。解决方法是给8080加一条firewalld规则只允许来自127.0.0.1的连接firewall-cmd --permanent --add-rich-rulerule familyipv4 source address127.0.0.1 port port8080 protocoltcp accept firewall-cmd --reload5.2 404的两个处境是路由问题还是接口问题404分两种处理方式完全不同页面404访问https://your-domain.com/about直接404。几乎可以断定是try_files没配置。在location /里加上那一行回退配置reload Nginx即可。接口404页面正常但某个接口调用返回404。先分清是Nginx层404还是后端404# 看本机curl后端接口 curl -v http://127.0.0.1:8080/api/login如果本机curl能通但浏览器不通把浏览器Network面板里那个接口的请求URL和后端Controller的RequestMapping值对一下大概率是前缀问题。我遇到一次的是后端接口路径是/user/login但Nginx配置用了带斜杠的proxy_pass http://127.0.0.1:8080/请求转发后被剥成了/login于是404。去掉Nginx代理地址末尾的斜杠就解决了。5.3 数据库连接失败和时间时区问题后端能启动、前台页面正常但一登录就报数据库错误这类问题在本地几乎不会出现因为本地数据库就在本机。上了服务器数据库连接失败最常见三种MySQL没开机自启。服务器重启后MySQL没起来Java进程在Spring Boot启动时连接失败导致整个应用起不来。解决方案是设置开机自启systemctl enable mysqld密码或账号不对。这里提醒一个坑MySQL 8.0默认的加密方式可能是caching_sha2_password老版本的Java驱动不认识会报Public Key Retrieval is not allowed。解决方案有两个换mysql-connector-java8.0以上的驱动版本或者在连接串里加allowPublicKeyRetrievaltrueuseSSLfalse。数据库时区问题。接口查出来的时间比实际时间早8小时这是老问题了。除了在连接串里加serverTimezoneAsia/Shanghai还建议把MySQL的时区也改掉vim /etc/my.cnf # 在 [mysqld] 下加 default-time-zone08:00顺便说个细节MySQL跑在服务器上连接串建议用内网IP而不是公网IP。因为公网IP绕了一圈可能走了云厂商的NAT网关或防火墙延迟高还可能被云安全策略拦截。同一台服务器内部互访用内网IP甚至127.0.0.1都行。5.4 前端CSS/JS加载404页面空白F12看到一堆JS/CSS文件404。这个问题在上线时特别常见原因有两个base路径不对。如果项目部署在子路径但vite.config.js里的base没改资源路径会指向根路径。改完重新npm run build。前端资源没更新。重新构建后的dist没有完整覆盖服务器上的旧文件。我建议每次部署前先删掉旧目录再传新的rm -rf /opt/frontend/dist/*5.5 排查逻辑先看网络再看进程最后看配置踩过这么多坑我总结出一个固定排查顺序按照这个顺序来不会乱网络层本机curl -I http://127.0.0.1:80通不通公网机器curl -I http://服务器IP通不通不通就查安全组和防火墙。进程层Nginx、后端Java进程、MySQL进程是否都在systemctl status逐个查。配置层Nginx配置语法、前端资源路径、后端环境配置逐个对。数据层数据库是否能连表结构是否完整种子数据是否导入大多数问题在第二步和第三步之间就能找到答案。养成按层排查的习惯就不至于东一榔头西一棒子地瞎试。6. 进阶玩法Docker化部署与自动化发版如果项目要长期维护、频繁发版再手动敲命令肯定不是长久之计。上线稳定后我把部署方式升级了一轮用Docker打包运行环境用Git WebHook触发自动化部署。这套组合下来发版从折腾半小时变成push代码就完事。6.1 Docker部署Web项目的完整流程Docker的核心价值是环境一致。本机能跑的镜像到服务器上也是一模一样不存在在我机器上是好的啊这种问题。先装Dockeryum install -y yum-utils yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo yum install -y docker-ce docker-ce-cli containerd.io systemctl start docker systemctl enable docker然后写Dockerfile。后端项目FROM openjdk:11-jre-slim WORKDIR /app COPY app.jar /app/app.jar EXPOSE 8080 ENTRYPOINT [java, -jar, /app/app.jar, --spring.profiles.activeprod]前端项目FROM node:16-alpine AS build WORKDIR /app COPY package*.json ./ RUN npm install COPY . . RUN npm run build FROM nginx: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;]MySQL也放到容器里为了保证数据不丢用Docker数据卷挂载docker volume create mysql-data docker run -d \ --name mysql \ -e MYSQL_ROOT_PASSWORD你的密码 \ -e MYSQL_DATABASE你的库名 \ -v mysql-data:/var/lib/mysql \ -p 3306:3306 \ mysql:8.0但更好的方式是使用docker-compose.yml把三个服务编排起来version: 3.8 services: mysql: image: mysql:8.0 container_name: mysql environment: MYSQL_ROOT_PASSWORD: yourpassword MYSQL_DATABASE: yourdb volumes: - mysql-data:/var/lib/mysql ports: - 3306:3306 restart: always backend: build: ./backend container_name: backend depends_on: - mysql environment: SPRING_PROFILES_ACTIVE: prod SPRING_DATASOURCE_URL: jdbc:mysql://mysql:3306/yourdb?useSSLfalseserverTimezoneAsia/Shanghai ports: - 8080:8080 restart: always frontend: build: ./frontend container_name: frontend depends_on: - backend ports: - 80:80 restart: always volumes: mysql-data:注意后端连接串里的主机名写的是mysql而不是IP。这是Docker Compose内置的DNS服务容器之间可以直接用服务名互联不用关心彼此的IP地址。这套编排的思想是docker-compose up -d一条命令MySQL、后端、前端全部拉起来。docker-compose up -d --build6.2 Git WebHook 宝塔面板实现push代码自动部署Docker解决的是环境一致但发版时还要ssh上去执行命令也很烦。后来我配了Git WebHook 宝塔面板的自动化流程项目push代码后服务器自动拉取、自动构建、自动重启。思路是这样的服务器上装宝塔面板。宝塔的宝塔WebHook插件能生成一个URL这个URL被访问时触发自定义脚本。项目推送代码时在Git仓库的WebHook设置里填上这个URL。服务器收到请求后执行脚本拉取代码 →mvn package或npm run build→ 重启服务。脚本大致这样以Java后端为例#!/bin/bash cd /project/backend git pull origin main mvn clean package -DskipTests systemctl restart app前端同理#!/bin/bash cd /project/frontend git pull origin main npm install npm run build rm -rf /opt/frontend/dist/* cp -r dist/* /opt/frontend/dist/这套跑通之后团队发版只需要git push剩下的交给服务器自己完成。我配的时候还踩过一个坑Git仓库拉取需要凭据建议用Deploy KeySSH Key方式而不是每次都输用户名密码否则自动化脚本会因为权限问题卡在git pull那一步。6.3 我的最终建议什么规模用什么方案这三种方式没有优劣之分只有合不合适个人学习项目、日PV几千的小站宝塔面板最舒服。图形化界面管理Nginx、MySQL部署快还有自动备份功能。因为你不需要关心集群、编排这些问题。正规商业项目、需要快速交付Docker Compose是性价比最高的方案。环境一致、便于回滚换镜像tag就行、扩展方便。团队项目、发版频繁Git WebHook或Jenkins自动化是解放生产力的关键。我用的Git WebHook方案轻量够用更大团队可以上Jenkins支持流水线、测试报告、多环境发布。我个人实践下来的心得是先手动部署通一遍再用Docker固化环境最后加自动化提升效率这个顺序踩坑最少。一上来就追新技术方案很容易在部署和工具本身的使用两座大山之间迷失方向。如果你现在正卡在本地跑通但线上打不开按这篇文章的链路从头对一遍后端进程起来了吗、数据库连上了吗、Nginx代理配全了吗、防火墙端口开了吗、前端路径对吗。99%的问题都能在链路上找到答案。剩下的1%重启大法偶尔也管用但记得先找到根因再重启否则它还会再回来找你。