1. 从“跑起来”到“稳下来”部署前后端分离项目的核心挑战如果你刚完成一个前后端分离项目的开发看着本地环境跑得顺风顺水然后兴冲冲地准备把它放到服务器上大概率会经历一个从“信心满满”到“焦头烂额”的过程。我见过太多团队开发阶段一切顺利一到部署环节各种跨域、接口404、静态资源加载失败、环境变量丢失的问题就全冒出来了。这背后的原因很简单本地开发环境比如用npm run serve和Spring Boot内嵌Tomcat和线上生产环境是两套完全不同的体系。部署本质上是在一个陌生的、约束更多的环境里把两套独立运行的程序前端静态资源服务 后端API服务重新组装成一个对外可访问的整体应用。所以这篇内容不是一份简单的命令清单。我想和你分享的是一套从零开始将前后端分离项目部署到Linux生产服务器的完整逻辑、实操细节以及那些文档里不会写的“坑”。我们会以最经典的Spring Boot Vue技术栈为例但其中涉及的网络、代理、路径、安全等思想适用于任何前后端分离架构如React、Angular搭配任何后端。我们的目标不仅仅是让项目“跑起来”更是让它以一种可靠、可维护、性能良好的方式“稳下来”。无论你用的是云服务器、虚拟机还是内网主机这套思路都能帮你理清头绪。2. 部署蓝图与核心组件选型为什么是Nginx 独立后端服务在动手敲命令之前我们必须先想清楚部署的架构。前后端分离后前端是一堆HTML、CSS、JavaScript文件后端是提供RESTful API的Java或其他语言应用。它们如何协同工作最常见的两种部署模式完全分离部署前端和后端分别使用独立的域名或端口部署在不同的服务器甚至不同的服务上。前端通过配置好的后端API地址如https://api.yourdomain.com直接请求。这种方式灵活便于独立扩展但需要处理跨域问题CORS。Nginx反向代理部署这是中小型项目和个人项目更主流、更简单的选择。我们只用一个域名如https://www.yourdomain.com通过Nginx这个高性能的Web服务器来“统一门户”。Nginx负责两件事托管前端静态文件当用户访问https://www.yourdomain.com时Nginx直接返回Vue打包好的index.html及相关的JS、CSS文件。反向代理后端API请求当前端JS代码需要调用API时比如请求/api/user/loginNginx会根据配置将这个请求转发到后端的Spring Boot应用比如运行在http://127.0.0.1:8080然后将结果返回给前端。对于浏览器来说它只和Nginx通信完美避开了跨域问题。为什么我强烈推荐第二种模式Nginx反向代理简化网络配置你只需要对外暴露80HTTP或443HTTPS端口后端服务可以藏在内部网络更安全。天然解决跨域前后端在浏览器看来同源无需在后端配置复杂的CORS策略。性能优化Nginx可以高效处理静态文件缓存响应压缩数据减轻后端压力。统一入口方便未来配置SSL证书、负载均衡、限流等高级功能。因此我们的部署架构非常清晰一台Linux服务器以CentOS 7/8或Ubuntu 20.04/22.04为例。后端Spring Boot项目打包成可执行的JAR文件在服务器上通过Java运行。中间层Nginx作为Web服务器和反向代理。前端Vue项目打包成静态文件由Nginx托管。接下来我们就按照这个蓝图一步步实现。3. 后端部署让Spring Boot应用在后台稳定运行后端的核心任务是脱离IDE在服务器上以服务的形式持续运行。这里的关键在于打包、传输和进程管理。3.1 项目打包与配置隔离在本地开发环境你的application.properties里可能写着spring.datasource.urljdbc:mysql://localhost:3306/dev_db。但生产环境的数据库地址、密码、Redis连接等信息绝不可能和开发环境相同。所以打包的第一步是做好配置隔离。标准做法是使用Spring Boot的Profile功能创建配置文件在src/main/resources/目录下除了application.properties创建application-prod.properties。配置生产环境参数在application-prod.properties中配置生产环境的数据库、Redis、文件路径等。敏感信息如密码切勿硬编码应使用环境变量或配置中心。这里我们先使用环境变量示例# application-prod.properties spring.datasource.url${DB_URL:jdbc:mysql://localhost:3306/prod_db} spring.datasource.username${DB_USERNAME} spring.datasource.password${DB_PASSWORD} # 使用生产环境日志级别 logging.level.rootINFO # 指定生产环境端口可选通常由外部配置 server.port8080打包命令在项目根目录下使用Maven或Gradle打包。务必跳过测试因为生产服务器可能没有测试环境。# Maven mvn clean package -DskipTests -Pprod # 或使用Spring Boot插件 mvn clean package spring-boot:repackage -DskipTests -Pprod-Pprod激活了prodprofile打包时会包含application-prod.properties的配置。最终在target目录下会生成一个your-project-name-0.0.1-SNAPSHOT.jar文件。这个JAR是“可执行的”它内嵌了Tomcat服务器。注意关于-Pprod参数这依赖于你在pom.xml中配置了profiles。更通用的方式是打包一个“干净”的JAR然后在服务器运行时通过--spring.profiles.activeprod参数来指定环境。这样同一个JAR包可以用于任何环境。我个人的习惯是后者因为它更灵活。3.2 服务器环境准备与文件传输假设你已经拥有一台安装了Linux的服务器并通过SSH连接。安装JavaSpring Boot应用需要JRE或JDK运行。检查是否已安装java -version。如果未安装以Ubuntu为例sudo apt update sudo apt install openjdk-11-jdk # 根据你的Spring Boot版本选择JDK 8, 11, 17等创建应用目录为你的项目创建一个专属目录结构清晰便于管理。sudo mkdir -p /opt/myapp/backend sudo chown -R $USER:$USER /opt/myapp # 将所有权改为当前用户方便操作传输JAR包从本地将打包好的JAR文件上传到服务器。推荐使用scp命令# 在本地终端执行 scp target/your-project-name-0.0.1-SNAPSHOT.jar useryour_server_ip:/opt/myapp/backend/也可以使用SFTP工具如FileZilla。3.3 进程管理与服务化告别nohup java -jar很多教程会教你用nohup java -jar app.jar 来启动应用。这确实能让进程在后台运行但它非常脆弱进程挂了不会自动重启服务器重启后需要手动启动不方便管理日志。生产环境绝对不要这样做。正确做法是使用系统服务管理器如Systemd现代Linux发行版标配。创建Systemd服务文件sudo vim /etc/systemd/system/myapp-backend.service编写服务配置[Unit] DescriptionMyApp Backend Service Afternetwork.target [Service] Typesimple Userwww-data # 建议使用非root用户运行更安全 WorkingDirectory/opt/myapp/backend ExecStart/usr/bin/java -jar -Dspring.profiles.activeprod your-project-name-0.0.1-SNAPSHOT.jar # 通过环境变量传递敏感信息更安全 EnvironmentDB_PASSWORDyour_strong_password_here # 重要配置JVM内存参数避免内存溢出 EnvironmentJAVA_OPTS-Xms512m -Xmx1024m -XX:UseG1GC ExecStop/bin/kill -15 $MAINPID Restartalways RestartSec10 StandardOutputjournal StandardErrorjournal [Install] WantedBymulti-user.target关键参数解析Userwww-data使用Nginx常用的www-data用户运行权限更低更安全。-Dspring.profiles.activeprod激活生产环境配置。Environment在这里设置环境变量然后在application-prod.properties中用${DB_PASSWORD}引用。JAVA_OPTS配置JVM堆内存。-Xms初始堆大小-Xmx最大堆大小。根据服务器内存调整如2G内存的服务器-Xmx可设为1536m。Restartalways服务异常退出时自动重启保障高可用。启动并启用服务sudo systemctl daemon-reload # 重新加载systemd配置 sudo systemctl start myapp-backend # 启动服务 sudo systemctl enable myapp-backend # 设置开机自启 sudo systemctl status myapp-backend # 查看服务状态如果状态显示active (running)并且用curl http://localhost:8080/api/health假设你有健康检查接口能收到响应说明后端服务已经在8080端口正常运行了。实操心得务必为服务配置合理的JVM参数。我曾遇到一个未配置-Xmx的服务在流量稍大时默默吃掉所有服务器内存最终被系统OOM Killer杀掉。通过journalctl -u myapp-backend -f可以实时查看服务日志这是排查问题的第一现场。4. 前端部署打包静态资源与Nginx配置的艺术前端部署的核心在于构建和放置。Vue、React等框架都需要先打包生成纯粹的HTML、JS、CSS文件。4.1 本地构建与路径陷阱在本地前端项目根目录下运行构建命令npm run build # 或 yarn build这会在项目下生成一个dist目录默认名称里面就是所有静态资源。这里有一个至关重要的坑静态资源的路径问题。Vue CLI默认的打包配置是假设你的应用被部署在域名的根路径下如https://www.yourdomain.com。如果你的前端想部署在子路径下如https://www.yourdomain.com/admin就需要配置publicPath。检查并修改vue.config.js如果没有则创建module.exports { // 如果你部署在根路径则为 ‘/‘ // 如果你部署在子路径如 ‘/admin/‘则设为 ‘/admin/‘ publicPath: process.env.NODE_ENV production ? / : /, // 其他配置... }为什么这很重要如果publicPath不对Nginx能找到index.html但HTML里引用的JS/CSS文件路径会是错的导致页面白屏或样式丢失。4.2 上传文件与Nginx核心配置将本地dist目录下的所有文件上传到服务器的某个目录例如/opt/myapp/frontend。现在来到重头戏配置Nginx。安装Nginx# Ubuntu sudo apt install nginx # CentOS sudo yum install nginx sudo systemctl start nginx sudo systemctl enable nginx配置站点不要直接修改默认的/etc/nginx/nginx.conf。最佳实践是在/etc/nginx/conf.d/目录下为每个站点创建一个独立的.conf文件。sudo vim /etc/nginx/conf.d/myapp.conf写入以下配置server { listen 80; server_name your_domain.com www.your_domain.com; # 请替换为你的域名或服务器IP # 前端静态文件服务 location / { root /opt/myapp/frontend; # 前端文件存放目录 index index.html index.htm; try_files $uri $uri/ /index.html; # 关键支持Vue/React的History路由模式 } # 反向代理后端API 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_set_header X-Forwarded-Proto $scheme; # 可选增加超时设置避免长请求超时 proxy_connect_timeout 60s; proxy_send_timeout 60s; proxy_read_timeout 60s; } # 可选代理WebSocket连接如果需要 # location /ws/ { # proxy_pass http://127.0.0.1:8080; # proxy_http_version 1.1; # proxy_set_header Upgrade $http_upgrade; # proxy_set_header Connection upgrade; # } # 可选静态资源缓存提升性能 location ~* \.(jpg|jpeg|png|gif|ico|css|js|svg|woff|woff2|ttf|eot)$ { root /opt/myapp/frontend; expires 1y; add_header Cache-Control public, immutable; } }配置详解server_name: 你的域名。如果暂时没有域名可以用服务器IP或者改成_下划线表示匹配所有。location /: 处理所有根路径请求。try_files $uri $uri/ /index.html;是单页应用SPA的灵魂配置。它的意思是先尝试找请求的文件$uri再尝试找对应的目录$uri/如果都找不到最后返回index.html。这样像/user/profile这样的前端路由就不会被Nginx当作文件路径去查找而是由前端index.html接管路由。location /api/: 所有以/api/开头的请求都会被转发到本机的8080端口即我们的Spring Boot应用。proxy_set_header系列指令是为了将客户端的真实IP等信息传递给后端否则后端日志里看到的全是127.0.0.1。静态资源缓存对图片、样式、字体等文件设置长期缓存利用浏览器缓存大幅提升重复访问速度。immutable告诉浏览器在缓存过期前文件内容绝不会改变无需再发请求验证。测试并重载Nginx配置sudo nginx -t # 测试配置文件语法是否正确 sudo systemctl reload nginx # 平滑重载配置不影响在线服务如果测试通过现在你应该能通过服务器的IP或配置的域名访问到前端页面了并且前端发起的/api/xxx请求也能正常拿到后端数据。5. 深度排错与性能调优从“能用”到“好用”部署成功只是第一步。接下来你会遇到各种“小毛病”这里汇总了最常见的坑和优化点。5.1 前端访问白屏或404这是最高频的问题排查链路如下检查Nginx错误日志sudo tail -f /var/log/nginx/error.log。看是否有权限错误Permission denied或找不到文件No such file or directory。确认文件路径和权限确保/opt/myapp/frontend目录及其下的文件Nginx进程用户通常是www-data或nginx有读取权限。sudo chown -R www-data:www-data /opt/myapp/frontend确认try_files指令务必在location /块中配置try_files $uri $uri/ /index.html;这是解决History路由模式404的关键。检查前端资源路径打开浏览器开发者工具F12的“网络”Network标签刷新页面。查看加载的JS、CSS文件是否返回200状态码。如果返回404说明publicPath配置有误或者Nginx的root路径不对。你需要对比浏览器请求的URL和文件在服务器的实际路径。5.2 后端API请求失败502/504错误Nginx返回502 Bad Gateway或504 Gateway Timeout说明Nginx与后端服务通信出了问题。502错误通常代表Nginx无法连接到后端服务。检查后端服务是否运行sudo systemctl status myapp-backend。检查后端服务端口sudo netstat -tlnp | grep :8080看8080端口是否在监听。检查防火墙如果后端服务与Nginx不在同一台机器或使用了非本地回环地址需要检查防火墙是否放行了端口。对于本机通信使用127.0.0.1通常没问题。504错误代表连接超时。后端处理请求时间过长超过了Nginx的proxy_read_timeout默认60秒。调整Nginx超时设置在location /api/块中增加proxy_read_timeout 300s;等根据你的业务需要调整。优化后端应用检查是否有慢查询、死循环或复杂计算。使用jstack或Arthas等工具分析后端线程状态。5.3 静态资源缓存与版本管理配置了强缓存后当你更新前端代码并重新部署时用户浏览器可能因为缓存而加载旧版本的文件。解决方案是使用文件指纹Hash。Vue/React等现代构建工具在打包时默认会给文件名加上哈希值如app.abc123.js。只要文件内容不变哈希就不变缓存生效文件内容一变哈希就变URL就变了浏览器自然会请求新文件。确保你的打包配置启用了这一点。在Nginx配置中我们对带哈希的资源设置长期缓存expires 1y而对index.html不设置缓存或设置很短如no-cache因为它是入口文件需要及时更新。5.4 开启HTTPS与HTTP/2生产环境必须使用HTTPS。你可以从云服务商或Let‘s Encrypt申请免费SSL证书。使用Certbot自动获取证书以Ubuntu Nginx为例sudo apt install certbot python3-certbot-nginx sudo certbot --nginx -d your_domain.com -d www.your_domain.comCertbot会自动修改你的Nginx配置添加SSL相关设置并设置自动续期。配置HTTP/2在获得SSL证书后Nginx配置中listen指令会变成listen 443 ssl http2;。HTTP/2可以显著提升页面加载性能。强制HTTP跳转HTTPS在原来的80端口server块中添加server { listen 80; server_name your_domain.com www.your_domain.com; return 301 https://$server_name$request_uri; # 永久重定向到HTTPS }5.5 基础安全加固隐藏Nginx版本信息在/etc/nginx/nginx.conf的http块中添加server_tokens off;。限制不必要的HTTP方法在API的location块中可以添加if ($request_method !~ ^(GET|HEAD|POST|PUT|PATCH|DELETE|OPTIONS)$) { return 405; }后端服务不以root运行如前所述在Systemd服务文件中使用Userwww-data。保持系统和软件更新定期运行sudo apt update sudo apt upgrade。6. 进阶考量容器化与持续集成部署CI/CD初探当项目迭代频繁手动部署变得繁琐且易错时就该考虑自动化了。容器化Docker和CI/CD是解决这个问题的标准答案。6.1 使用Docker容器化部署为前后端分别编写Dockerfile将环境依赖和应用程序一起打包成镜像。这样做的好处是环境一致一次构建到处运行。后端Dockerfile示例# 使用官方Java基础镜像 FROM openjdk:11-jre-slim # 设置工作目录 WORKDIR /app # 将构建好的JAR包复制到容器中 COPY target/your-project-name-0.0.1-SNAPSHOT.jar app.jar # 暴露端口 EXPOSE 8080 # 设置JVM参数和环境变量 ENV JAVA_OPTS-Xms512m -Xmx1024m ENV SPRING_PROFILES_ACTIVEprod # 启动命令 ENTRYPOINT [sh, -c, java $JAVA_OPTS -jar app.jar]前端Dockerfile示例# 构建阶段 FROM node:16-alpine as build WORKDIR /app COPY package*.json ./ RUN npm ci --onlyproduction 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然后使用docker-compose.yml来编排前后端容器和网络一键启动整个应用栈。这大大简化了部署复杂度。6.2 搭建最简单的CI/CD流水线利用GitHub Actions、GitLab CI或Jenkins可以实现代码推送后自动构建、测试、打包镜像并部署到服务器。一个简化的GitHub Actions流程.github/workflows/deploy.yml思路如下触发监听main分支的push事件。构建在GitHub提供的虚拟机上拉取代码安装依赖运行测试构建前端和后端。打包根据Dockerfile构建Docker镜像并推送到Docker Hub或私有镜像仓库。部署通过SSH连接到你的生产服务器拉取最新的镜像停止旧容器启动新容器。这实现了“git push”即部署的自动化流程是团队协作和快速迭代的基石。从手动部署到自动化部署是一个项目走向成熟和规范的标志。虽然初期搭建需要一些投入但它带来的部署速度、一致性和可靠性的提升对于长期项目而言是绝对值得的。希望这篇从原理到实操再到排错和进阶的详细梳理能帮你彻底打通前后端分离项目部署的任督二脉。
Spring Boot+Vue项目部署实战：Nginx反向代理与生产环境配置详解
发布时间：2026/7/30 5:56:06
1. 从“跑起来”到“稳下来”部署前后端分离项目的核心挑战如果你刚完成一个前后端分离项目的开发看着本地环境跑得顺风顺水然后兴冲冲地准备把它放到服务器上大概率会经历一个从“信心满满”到“焦头烂额”的过程。我见过太多团队开发阶段一切顺利一到部署环节各种跨域、接口404、静态资源加载失败、环境变量丢失的问题就全冒出来了。这背后的原因很简单本地开发环境比如用npm run serve和Spring Boot内嵌Tomcat和线上生产环境是两套完全不同的体系。部署本质上是在一个陌生的、约束更多的环境里把两套独立运行的程序前端静态资源服务 后端API服务重新组装成一个对外可访问的整体应用。所以这篇内容不是一份简单的命令清单。我想和你分享的是一套从零开始将前后端分离项目部署到Linux生产服务器的完整逻辑、实操细节以及那些文档里不会写的“坑”。我们会以最经典的Spring Boot Vue技术栈为例但其中涉及的网络、代理、路径、安全等思想适用于任何前后端分离架构如React、Angular搭配任何后端。我们的目标不仅仅是让项目“跑起来”更是让它以一种可靠、可维护、性能良好的方式“稳下来”。无论你用的是云服务器、虚拟机还是内网主机这套思路都能帮你理清头绪。2. 部署蓝图与核心组件选型为什么是Nginx 独立后端服务在动手敲命令之前我们必须先想清楚部署的架构。前后端分离后前端是一堆HTML、CSS、JavaScript文件后端是提供RESTful API的Java或其他语言应用。它们如何协同工作最常见的两种部署模式完全分离部署前端和后端分别使用独立的域名或端口部署在不同的服务器甚至不同的服务上。前端通过配置好的后端API地址如https://api.yourdomain.com直接请求。这种方式灵活便于独立扩展但需要处理跨域问题CORS。Nginx反向代理部署这是中小型项目和个人项目更主流、更简单的选择。我们只用一个域名如https://www.yourdomain.com通过Nginx这个高性能的Web服务器来“统一门户”。Nginx负责两件事托管前端静态文件当用户访问https://www.yourdomain.com时Nginx直接返回Vue打包好的index.html及相关的JS、CSS文件。反向代理后端API请求当前端JS代码需要调用API时比如请求/api/user/loginNginx会根据配置将这个请求转发到后端的Spring Boot应用比如运行在http://127.0.0.1:8080然后将结果返回给前端。对于浏览器来说它只和Nginx通信完美避开了跨域问题。为什么我强烈推荐第二种模式Nginx反向代理简化网络配置你只需要对外暴露80HTTP或443HTTPS端口后端服务可以藏在内部网络更安全。天然解决跨域前后端在浏览器看来同源无需在后端配置复杂的CORS策略。性能优化Nginx可以高效处理静态文件缓存响应压缩数据减轻后端压力。统一入口方便未来配置SSL证书、负载均衡、限流等高级功能。因此我们的部署架构非常清晰一台Linux服务器以CentOS 7/8或Ubuntu 20.04/22.04为例。后端Spring Boot项目打包成可执行的JAR文件在服务器上通过Java运行。中间层Nginx作为Web服务器和反向代理。前端Vue项目打包成静态文件由Nginx托管。接下来我们就按照这个蓝图一步步实现。3. 后端部署让Spring Boot应用在后台稳定运行后端的核心任务是脱离IDE在服务器上以服务的形式持续运行。这里的关键在于打包、传输和进程管理。3.1 项目打包与配置隔离在本地开发环境你的application.properties里可能写着spring.datasource.urljdbc:mysql://localhost:3306/dev_db。但生产环境的数据库地址、密码、Redis连接等信息绝不可能和开发环境相同。所以打包的第一步是做好配置隔离。标准做法是使用Spring Boot的Profile功能创建配置文件在src/main/resources/目录下除了application.properties创建application-prod.properties。配置生产环境参数在application-prod.properties中配置生产环境的数据库、Redis、文件路径等。敏感信息如密码切勿硬编码应使用环境变量或配置中心。这里我们先使用环境变量示例# application-prod.properties spring.datasource.url${DB_URL:jdbc:mysql://localhost:3306/prod_db} spring.datasource.username${DB_USERNAME} spring.datasource.password${DB_PASSWORD} # 使用生产环境日志级别 logging.level.rootINFO # 指定生产环境端口可选通常由外部配置 server.port8080打包命令在项目根目录下使用Maven或Gradle打包。务必跳过测试因为生产服务器可能没有测试环境。# Maven mvn clean package -DskipTests -Pprod # 或使用Spring Boot插件 mvn clean package spring-boot:repackage -DskipTests -Pprod-Pprod激活了prodprofile打包时会包含application-prod.properties的配置。最终在target目录下会生成一个your-project-name-0.0.1-SNAPSHOT.jar文件。这个JAR是“可执行的”它内嵌了Tomcat服务器。注意关于-Pprod参数这依赖于你在pom.xml中配置了profiles。更通用的方式是打包一个“干净”的JAR然后在服务器运行时通过--spring.profiles.activeprod参数来指定环境。这样同一个JAR包可以用于任何环境。我个人的习惯是后者因为它更灵活。3.2 服务器环境准备与文件传输假设你已经拥有一台安装了Linux的服务器并通过SSH连接。安装JavaSpring Boot应用需要JRE或JDK运行。检查是否已安装java -version。如果未安装以Ubuntu为例sudo apt update sudo apt install openjdk-11-jdk # 根据你的Spring Boot版本选择JDK 8, 11, 17等创建应用目录为你的项目创建一个专属目录结构清晰便于管理。sudo mkdir -p /opt/myapp/backend sudo chown -R $USER:$USER /opt/myapp # 将所有权改为当前用户方便操作传输JAR包从本地将打包好的JAR文件上传到服务器。推荐使用scp命令# 在本地终端执行 scp target/your-project-name-0.0.1-SNAPSHOT.jar useryour_server_ip:/opt/myapp/backend/也可以使用SFTP工具如FileZilla。3.3 进程管理与服务化告别nohup java -jar很多教程会教你用nohup java -jar app.jar 来启动应用。这确实能让进程在后台运行但它非常脆弱进程挂了不会自动重启服务器重启后需要手动启动不方便管理日志。生产环境绝对不要这样做。正确做法是使用系统服务管理器如Systemd现代Linux发行版标配。创建Systemd服务文件sudo vim /etc/systemd/system/myapp-backend.service编写服务配置[Unit] DescriptionMyApp Backend Service Afternetwork.target [Service] Typesimple Userwww-data # 建议使用非root用户运行更安全 WorkingDirectory/opt/myapp/backend ExecStart/usr/bin/java -jar -Dspring.profiles.activeprod your-project-name-0.0.1-SNAPSHOT.jar # 通过环境变量传递敏感信息更安全 EnvironmentDB_PASSWORDyour_strong_password_here # 重要配置JVM内存参数避免内存溢出 EnvironmentJAVA_OPTS-Xms512m -Xmx1024m -XX:UseG1GC ExecStop/bin/kill -15 $MAINPID Restartalways RestartSec10 StandardOutputjournal StandardErrorjournal [Install] WantedBymulti-user.target关键参数解析Userwww-data使用Nginx常用的www-data用户运行权限更低更安全。-Dspring.profiles.activeprod激活生产环境配置。Environment在这里设置环境变量然后在application-prod.properties中用${DB_PASSWORD}引用。JAVA_OPTS配置JVM堆内存。-Xms初始堆大小-Xmx最大堆大小。根据服务器内存调整如2G内存的服务器-Xmx可设为1536m。Restartalways服务异常退出时自动重启保障高可用。启动并启用服务sudo systemctl daemon-reload # 重新加载systemd配置 sudo systemctl start myapp-backend # 启动服务 sudo systemctl enable myapp-backend # 设置开机自启 sudo systemctl status myapp-backend # 查看服务状态如果状态显示active (running)并且用curl http://localhost:8080/api/health假设你有健康检查接口能收到响应说明后端服务已经在8080端口正常运行了。实操心得务必为服务配置合理的JVM参数。我曾遇到一个未配置-Xmx的服务在流量稍大时默默吃掉所有服务器内存最终被系统OOM Killer杀掉。通过journalctl -u myapp-backend -f可以实时查看服务日志这是排查问题的第一现场。4. 前端部署打包静态资源与Nginx配置的艺术前端部署的核心在于构建和放置。Vue、React等框架都需要先打包生成纯粹的HTML、JS、CSS文件。4.1 本地构建与路径陷阱在本地前端项目根目录下运行构建命令npm run build # 或 yarn build这会在项目下生成一个dist目录默认名称里面就是所有静态资源。这里有一个至关重要的坑静态资源的路径问题。Vue CLI默认的打包配置是假设你的应用被部署在域名的根路径下如https://www.yourdomain.com。如果你的前端想部署在子路径下如https://www.yourdomain.com/admin就需要配置publicPath。检查并修改vue.config.js如果没有则创建module.exports { // 如果你部署在根路径则为 ‘/‘ // 如果你部署在子路径如 ‘/admin/‘则设为 ‘/admin/‘ publicPath: process.env.NODE_ENV production ? / : /, // 其他配置... }为什么这很重要如果publicPath不对Nginx能找到index.html但HTML里引用的JS/CSS文件路径会是错的导致页面白屏或样式丢失。4.2 上传文件与Nginx核心配置将本地dist目录下的所有文件上传到服务器的某个目录例如/opt/myapp/frontend。现在来到重头戏配置Nginx。安装Nginx# Ubuntu sudo apt install nginx # CentOS sudo yum install nginx sudo systemctl start nginx sudo systemctl enable nginx配置站点不要直接修改默认的/etc/nginx/nginx.conf。最佳实践是在/etc/nginx/conf.d/目录下为每个站点创建一个独立的.conf文件。sudo vim /etc/nginx/conf.d/myapp.conf写入以下配置server { listen 80; server_name your_domain.com www.your_domain.com; # 请替换为你的域名或服务器IP # 前端静态文件服务 location / { root /opt/myapp/frontend; # 前端文件存放目录 index index.html index.htm; try_files $uri $uri/ /index.html; # 关键支持Vue/React的History路由模式 } # 反向代理后端API 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_set_header X-Forwarded-Proto $scheme; # 可选增加超时设置避免长请求超时 proxy_connect_timeout 60s; proxy_send_timeout 60s; proxy_read_timeout 60s; } # 可选代理WebSocket连接如果需要 # location /ws/ { # proxy_pass http://127.0.0.1:8080; # proxy_http_version 1.1; # proxy_set_header Upgrade $http_upgrade; # proxy_set_header Connection upgrade; # } # 可选静态资源缓存提升性能 location ~* \.(jpg|jpeg|png|gif|ico|css|js|svg|woff|woff2|ttf|eot)$ { root /opt/myapp/frontend; expires 1y; add_header Cache-Control public, immutable; } }配置详解server_name: 你的域名。如果暂时没有域名可以用服务器IP或者改成_下划线表示匹配所有。location /: 处理所有根路径请求。try_files $uri $uri/ /index.html;是单页应用SPA的灵魂配置。它的意思是先尝试找请求的文件$uri再尝试找对应的目录$uri/如果都找不到最后返回index.html。这样像/user/profile这样的前端路由就不会被Nginx当作文件路径去查找而是由前端index.html接管路由。location /api/: 所有以/api/开头的请求都会被转发到本机的8080端口即我们的Spring Boot应用。proxy_set_header系列指令是为了将客户端的真实IP等信息传递给后端否则后端日志里看到的全是127.0.0.1。静态资源缓存对图片、样式、字体等文件设置长期缓存利用浏览器缓存大幅提升重复访问速度。immutable告诉浏览器在缓存过期前文件内容绝不会改变无需再发请求验证。测试并重载Nginx配置sudo nginx -t # 测试配置文件语法是否正确 sudo systemctl reload nginx # 平滑重载配置不影响在线服务如果测试通过现在你应该能通过服务器的IP或配置的域名访问到前端页面了并且前端发起的/api/xxx请求也能正常拿到后端数据。5. 深度排错与性能调优从“能用”到“好用”部署成功只是第一步。接下来你会遇到各种“小毛病”这里汇总了最常见的坑和优化点。5.1 前端访问白屏或404这是最高频的问题排查链路如下检查Nginx错误日志sudo tail -f /var/log/nginx/error.log。看是否有权限错误Permission denied或找不到文件No such file or directory。确认文件路径和权限确保/opt/myapp/frontend目录及其下的文件Nginx进程用户通常是www-data或nginx有读取权限。sudo chown -R www-data:www-data /opt/myapp/frontend确认try_files指令务必在location /块中配置try_files $uri $uri/ /index.html;这是解决History路由模式404的关键。检查前端资源路径打开浏览器开发者工具F12的“网络”Network标签刷新页面。查看加载的JS、CSS文件是否返回200状态码。如果返回404说明publicPath配置有误或者Nginx的root路径不对。你需要对比浏览器请求的URL和文件在服务器的实际路径。5.2 后端API请求失败502/504错误Nginx返回502 Bad Gateway或504 Gateway Timeout说明Nginx与后端服务通信出了问题。502错误通常代表Nginx无法连接到后端服务。检查后端服务是否运行sudo systemctl status myapp-backend。检查后端服务端口sudo netstat -tlnp | grep :8080看8080端口是否在监听。检查防火墙如果后端服务与Nginx不在同一台机器或使用了非本地回环地址需要检查防火墙是否放行了端口。对于本机通信使用127.0.0.1通常没问题。504错误代表连接超时。后端处理请求时间过长超过了Nginx的proxy_read_timeout默认60秒。调整Nginx超时设置在location /api/块中增加proxy_read_timeout 300s;等根据你的业务需要调整。优化后端应用检查是否有慢查询、死循环或复杂计算。使用jstack或Arthas等工具分析后端线程状态。5.3 静态资源缓存与版本管理配置了强缓存后当你更新前端代码并重新部署时用户浏览器可能因为缓存而加载旧版本的文件。解决方案是使用文件指纹Hash。Vue/React等现代构建工具在打包时默认会给文件名加上哈希值如app.abc123.js。只要文件内容不变哈希就不变缓存生效文件内容一变哈希就变URL就变了浏览器自然会请求新文件。确保你的打包配置启用了这一点。在Nginx配置中我们对带哈希的资源设置长期缓存expires 1y而对index.html不设置缓存或设置很短如no-cache因为它是入口文件需要及时更新。5.4 开启HTTPS与HTTP/2生产环境必须使用HTTPS。你可以从云服务商或Let‘s Encrypt申请免费SSL证书。使用Certbot自动获取证书以Ubuntu Nginx为例sudo apt install certbot python3-certbot-nginx sudo certbot --nginx -d your_domain.com -d www.your_domain.comCertbot会自动修改你的Nginx配置添加SSL相关设置并设置自动续期。配置HTTP/2在获得SSL证书后Nginx配置中listen指令会变成listen 443 ssl http2;。HTTP/2可以显著提升页面加载性能。强制HTTP跳转HTTPS在原来的80端口server块中添加server { listen 80; server_name your_domain.com www.your_domain.com; return 301 https://$server_name$request_uri; # 永久重定向到HTTPS }5.5 基础安全加固隐藏Nginx版本信息在/etc/nginx/nginx.conf的http块中添加server_tokens off;。限制不必要的HTTP方法在API的location块中可以添加if ($request_method !~ ^(GET|HEAD|POST|PUT|PATCH|DELETE|OPTIONS)$) { return 405; }后端服务不以root运行如前所述在Systemd服务文件中使用Userwww-data。保持系统和软件更新定期运行sudo apt update sudo apt upgrade。6. 进阶考量容器化与持续集成部署CI/CD初探当项目迭代频繁手动部署变得繁琐且易错时就该考虑自动化了。容器化Docker和CI/CD是解决这个问题的标准答案。6.1 使用Docker容器化部署为前后端分别编写Dockerfile将环境依赖和应用程序一起打包成镜像。这样做的好处是环境一致一次构建到处运行。后端Dockerfile示例# 使用官方Java基础镜像 FROM openjdk:11-jre-slim # 设置工作目录 WORKDIR /app # 将构建好的JAR包复制到容器中 COPY target/your-project-name-0.0.1-SNAPSHOT.jar app.jar # 暴露端口 EXPOSE 8080 # 设置JVM参数和环境变量 ENV JAVA_OPTS-Xms512m -Xmx1024m ENV SPRING_PROFILES_ACTIVEprod # 启动命令 ENTRYPOINT [sh, -c, java $JAVA_OPTS -jar app.jar]前端Dockerfile示例# 构建阶段 FROM node:16-alpine as build WORKDIR /app COPY package*.json ./ RUN npm ci --onlyproduction 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然后使用docker-compose.yml来编排前后端容器和网络一键启动整个应用栈。这大大简化了部署复杂度。6.2 搭建最简单的CI/CD流水线利用GitHub Actions、GitLab CI或Jenkins可以实现代码推送后自动构建、测试、打包镜像并部署到服务器。一个简化的GitHub Actions流程.github/workflows/deploy.yml思路如下触发监听main分支的push事件。构建在GitHub提供的虚拟机上拉取代码安装依赖运行测试构建前端和后端。打包根据Dockerfile构建Docker镜像并推送到Docker Hub或私有镜像仓库。部署通过SSH连接到你的生产服务器拉取最新的镜像停止旧容器启动新容器。这实现了“git push”即部署的自动化流程是团队协作和快速迭代的基石。从手动部署到自动化部署是一个项目走向成熟和规范的标志。虽然初期搭建需要一些投入但它带来的部署速度、一致性和可靠性的提升对于长期项目而言是绝对值得的。希望这篇从原理到实操再到排错和进阶的详细梳理能帮你彻底打通前后端分离项目部署的任督二脉。
