Spring Boot + Vue 前后端分离项目部署到阿里云 ECS 实战指南-代码聚汇网

Spring Boot + Vue 前后端分离项目部署到阿里云 ECS 实战指南

Spring BootVue阿里云ECS

|难度：普通|阅读约 48 分钟

1. 明明本地能跑，一上服务器就崩：先说这次要解决的核心问题

很多第一次买云服务器的人，都会经历一个非常魔幻的阶段：项目在自己电脑上 Spring Boot 启动秒开、Vue 页面切换流畅，朋友访问时也一切正常。但只要把它部署到阿里云 ECS 上，各种问题就全冒出来了——后端起来没几秒就挂了、前端页面白屏、接口请求 pending 半天、Nginx 反代配完后前端找不到后端，最后只能在朋友圈留下一句"服务器部署好难"。

这个现象背后其实不复杂，问题往往不出在代码本身，而出在大多数人从来没有完整地搞清楚一件事：本地开发环境和生产部署环境是两个完全不同的世界。你本地跑起来靠的是 IDE 帮你注入的开发配置，前端页面靠的是 npm run dev 的热更新服务器。而线上没有 IDE、没有 Node 开发服务器，只有一个安装好 Java、Node、Nginx 的干净操作系统，代码要以产物形式交付给反向代理和服务进程去托管。

所以这篇文章要做的，不是贴一个"照着敲就能成功"的满屏命令，而是把"从零到一"过程中每一步背后的原理和坑讲清楚。我会以一个前后端分离的个人项目为例，后端是 Spring Boot（打成 jar 包运行），前端是 Vue 3（构建为静态文件），部署目标是阿里云 ECS 上的一台 Linux 系统。不管版本是小版本不同还是目录结构略有差距，核心过程都完全一样。无论你是刚开始学部署的学生，还是准备把第一个正式项目挂到公网的开发者，这篇都能直接当操作手册用。

在往下走之前，想先跟你统一一下预期：整条部署链路其实是四个环节——服务器环境准备 → 后端打包并启动 → 前端构建并交付 → Nginx 反向代理拼接前后端。任何一步错了，最终表现都是项目访问不了，但排查方向完全不同。所以我的讲述顺序就是实战排查的顺序：先保证代码能在服务器上跑起来，再解决公网访问的问题。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 服务器选型与初始化：买完 ECS 后的第一小时该做什么

2.1 买一台什么配置的 ECS 才不浪费钱

阿里云 ECS 的实例规格五花八门，新人套餐也很诱人，但选配置前先问自己一个问题：这个项目要服务多少人？

如果你只是个人项目、毕业设计、学习练手，日活也就是你自己和几个朋友，那 2 核 4G 的入门实例完全够用。为什么不是 1 核 2G？因为 Spring Boot 应用本身启动时就很吃内存，一个包含了常用依赖的 jar 包跑起来，JVM 默认堆内存加元空间、线程栈，动辄占掉 700MB 到 1GB，再叠加 Nginx、可能的 MySQL、Redis，2G 内存会非常紧张。我见过很多人在 1 核 2G 上部署成功但系统负载居高不下，随便来个人访问接口就卡半天的例子。如果预算实在有限，1 核 2G 也并非不行，后面会给 JVM 参数调优的方法，但从体验角度，2 核 4G 属于"不心疼且少踩坑"的甜点配置。

系统镜像方面，推荐选择 Ubuntu 22.04 LTS 或 Debian 12，不要纠结 CentOS。原因有两个：一是社区主流教程、软件源兼容性都在往 Ubuntu/Debian 倾斜；二是 systemd、apt 生态在配置时更省心。如果你之前完全没接触过 Linux，Ubuntu 的报错信息更友好，百度上能搜到的解决方案也多。

地域选择上，正常情况下选离你目标用户最近的区域即可。国内访问没有明显区别，你在国内就选华南或华东都能很快。带宽方面，按固定带宽 1M 到 3M 就够测试和个人项目用，如果是图片或视频类资源比较多，建议按量计费，否则流量峰值时期会直接卡爆。

2.2 安全组配置：为什么你明明启动了服务却始终访问不了

这是新手阶段的第一个重大分水岭。很多人买完服务器，装上 JDK、MySQL，欢天喜地把 Spring Boot 项目拉起来，在服务器上 curl localhost:8080 发现返回数据了，于是兴冲冲地用浏览器访问服务器公网 IP:8080，结果一直超时。然后开始怀疑代码有问题、防火墙没关、端口被占用，折腾半天依然没有效果。

真相往往特别简单：阿里云 ECS 有一个外层安全组，默认只放行了 22 端口（SSH），其他端口全部拒绝。这是云平台的安全机制，作用等同于在虚拟机外面又套了一层防火墙。你的服务进程虽然正常监听在 8080 端口，但公网的请求根本到不了操作系统内部，更别说到达 Spring Boot。

解决办法很直接：在阿里云控制台找到"安全组"配置入口，点击"配置规则"→"入方向"→"手动添加"，把需要用到的端口放行。这里的关键是养成按最小权限放行的习惯，不要图省事直接添加 0.0.0.0/0 加所有端口，那等于把服务器裸奔在公网上。

拿一个典型项目来举例，需要放行的入方向规则一般是这几个：

端口	协议	授权对象	用途
22	TCP	你自己的 IP（或 0.0.0.0/0）	SSH 远程管理
80	TCP	0.0.0.0/0	HTTP 访问
443	TCP	0.0.0.0/0	HTTPS 访问（后面配证书用）
3306	TCP	仅你的开发机 IP	MySQL 远程管理（不建议长期开放）
8080	TCP	仅你的开发机 IP	后端临时调试

需要注意 8080 这种后端端口，如果 Nginx 已经代理了，其实可以完全不用对公网开放。真正要对公网开放的只有 80 和 443，其他都走内网回源或限定 IP。我在正式部署时，3306 和 8080 都是不放行的，生产环境根本不给你直接连数据库的机会。

2.3 登录服务器后必做的三件小事

SSH 登录上服务器之后，不要急着装环境，先把三件基础工作做了，后面会省掉很多莫名其妙的坑。

第一件：更新软件源。执行 sudo apt update && sudo apt upgrade -y，让系统包保持最新。有时候新买的实例自带源版本很老，直接装软件可能会碰到依赖冲突。

第二件：创建一个普通用户并配置 sudo 权限（如果你现在用的不是 root）。实际工作中没人用 root 天天跑服务，万一某个脚本写错了把系统搞挂，重建成本太高。执行 adduser deploy 然后 usermod -aG sudo deploy，后续都用这个用户操作。很多新手的习惯是不管什么都用 root，说实话个人练手项目问题不大，但从一开始养成好习惯，未来接手正式项目时会从容很多。

第三件：统一项目目录结构。我个人的习惯是：

bash复制/opt/myapp          # 存放后端 jar 和部署脚本
/opt/myapp/logs     # 后端运行日志
/var/www/myapp      # 前端静态文件
/etc/nginx/sites-available   # Nginx 站点配置

为什么不用 root 家目录或者 /usr/local 之类的路径？因为 /opt 的定位就是"第三方应用程序的安装目录"，团队协作时你一说路径别人就懂；/var/www 在 Linux 上是 Web 静态资源的传统站点目录。合理的目录规划会让你在日后查找文件、编写 systemd 服务、配置 Nginx root 时思路非常清晰。

至此，服务器才算是"可登录可用"状态。下面开始进入真正的部署实操环节。

3. 后端 Spring Boot：从"本地能跑"变成"服务器上能活"

3.1 先理解为什么 Spring Boot 项目要打包成 jar

很多人在本地跑 Spring Boot 项目时，靠的是 IDEA 或 Eclipse 点了那个绿色小三角，根本不清楚代码是怎么被执行起来的。Spring Boot 内嵌了 Tomcat，它在开发阶段通过 main 方法启动，然后加载 application.yml 里配置的数据源、Redis、自定义参数。但当你把它部署到服务器时，不可能在服务器上也装一个 IDEA，所以我们必须把整个项目"重装"成一个可以在任意装有 JDK 的机器上直接运行的东西——可执行 jar 包。

这个 jar 和传统意义上的依赖库 jar 完全不同。Spring Boot Maven 插件会把你的业务代码、所有第三方依赖、内嵌的 Tomcat 全部打进去，形成一个"自带应用服务器的单体"。运行它的唯一前提就是系统里有对应版本的 JDK。这也是 Spring Boot 部署比传统 SSM 项目（要单独装 Tomcat 再丢 war 包）简单得多的根本原因。

打包命令在项目根目录（也就是 pom.xml 所在目录）执行：

bash复制mvn clean package -DskipTests

这里的 -DskipTests 很关键。如果你的项目中有集成测试类，而测试类依赖了本地数据库、Redis 或者其他外部服务，在打包阶段执行测试十有八九会失败，导致整个打包过程前功尽弃。能跑通 CI/CD 流水线之后，我再建议你单独维护测试阶段，初期快速部署直接跳过测试是务实的做法。

打包完成后，在 target 目录下会出现一个形如 myapp-0.0.1-SNAPSHOT.jar 的文件，这就是我们要的产物。可以用 ls -lh target/*.jar 看下大小，通常在 30MB 到 100MB 之间，如果只有几 KB，说明打包没成功，多半是回到 IDE 里配置 Maven 插件了。

3.2 生产环境配置如何与本地分离：application-prod.yml

你在本地跑得好好的，为什么部署到服务器上总是连不上数据库？大概率因为你的 application.yml 里写死了 localhost:3306。本地 MySQL 就在本机，而服务器上的 MySQL 可能在另一台机器上，或者你还没装 MySQL。

正确的做法是把项目拆成多环境配置。Spring Boot 原生支持这种机制：application.yml 是公共配置，application-dev.yml 是开发环境，application-prod.yml 是生产环境。启动时通过 spring.profiles.active 指定激活哪一份。

打包之前，需要先确认你的 pom.xml 里是不是已经引入：

xml复制<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>

如果在项目里用了 @ConfigurationProperties 并且还没完善配置，快速部署的妥协方案是：先直接在 application.yml 中把数据库地址改成服务器的内网地址或 127.0.0.1，等跑通后再拆环境文件。但一个正经项目从开发第一天就该拆好环境，这是我在实战中反复吃教训得出的结论。分享一个极简的拆分思路：

bash复制# application.yml（公共）
spring:
  profiles:
    active: @spring.profiles.active@

bash复制# application-prod.yml
server:
  port: 8080
spring:
  datasource:
    url: jdbc:mysql://localhost:3306/myapp?useUnicode=true&characterEncoding=utf8&useSSL=false
    username: myappuser
    password: 你的强密码

关键是 @spring.profiles.active@ 这种写法，它会让 Maven 在打包时读取代 profile 属性，在 pom.xml 中配置：

xml复制<profiles>
    <profile>
        <id>prod</id>
        <properties>
            <spring.profiles.active>prod</spring.profiles.active>
        </properties>
    </profile>
</profiles>

然后打包命令变成 mvn clean package -DskipTests -Pprod，这样打出来的 jar 启动默认就是生产配置。

3.3 上传 jar 到服务器并想办法让它"不退出"

把 jar 上传到服务器有很多途径，最朴素的是用 scp 命令：

bash复制scp target/myapp-0.0.1-SNAPSHOT.jar deploy@你的公网IP:/opt/myapp/

如果有公网带宽比较慢，也可以先用压缩软件传到 OSS 再从服务器拉取，但个人项目 scp 足够用了。

上传完成后，你如果在服务器上直接执行 java -jar myapp.jar，项目确实能启动，可一旦你关闭 SSH 终端，进程就会被 SIGHUP 信号杀掉。新手很容易卡在这个地方：人离开电脑，项目就挂了。所以必须借助 Linux 的服务托管机制来常驻运行。这里我不推荐用 nohup 这种裸奔方式，而是推荐用 systemd。在后面第 6 节我会把 service 文件完整写出来，这里先提一句，你可以直接把重点放到"打出来的 jar 在服务器上能不能正常通过 java -jar 启动"这个验证点上。

先手动跑一次才是稳妥做法：

bash复制cd /opt/myapp
java -jar myapp-0.0.1-SNAPSHOT.jar --spring.profiles.active=prod

看到 Started Application in xxx seconds 字样后，另开一个终端用 curl http://localhost:8080/api/ping 测一下接口。如果能返回正常结果，说明进程本身没问题，接下来才能放心交给 systemd 托管。

4. 前端 Vue：npm run build 之后，你要交付的到底是什么

4.1 本地运行好好的页面，为什么打包后白屏

Vue 开发时执行 npm run serve，本质上是用 Webpack 或 Vite 起了一个开发服务器，实时编译 .vue 文件并在内存中提供热更新。整个过程中，浏览器请求的其实是 Node 服务器处理的动态资源。而生产环境根本没有 Node 开发进程，也完全不需要它。

执行 npm run build 后，构建工具会把你的整个应用"编译并压缩"成一组纯静态文件：index.html、CSS、JS、图片资源等。它们之间靠相对或绝对路径引用，最后由 Nginx 这类 Web 服务器托管目录，浏览器访问时再把这些静态文件下载渲染。

如果你在 npm run build 之后直接双击打开本地 dist/index.html，多半会白屏或路由失效。因为 Vue 项目的资源路径和路由方式决定了它必须通过 HTTP 服务在特定路径下访问。这点要先有认知，否则你把 dist 传到服务器上也不会好到哪去。

一个典型问题：资源路径配置错误。在 vue.config.js 中，如果 publicPath 没有设置为相对路径或你的域名子路径，那构建出来的 index.html 里引用的可能都是 /js/app.js 这种根路径。如果最终站点是放在域名根路径下，那没问题；如果放在子目录下，就会 404。个人项目一般直接部署在域名根路径，所以可以这样设置：

js复制// vue.config.js
module.exports = {
  publicPath: '/',
  outputDir: 'dist',
  assetsDir: 'static',
  productionSourceMap: false
}

productionSourceMap: false 有一点需要记住：不生成 sourcemap 文件，缩减构建体积，也避免前端代码被轻易还原。

4.2 常见构建失败与 Node 版本不对的问题

我见过最多的前端部署失败，其实发生在构建阶段，而不是上传之后。典型表现是本地 node_modules 装得好好的，换一台机器或过几个月重新 npm install 就报错，或者执行 npm run build 时抛出一堆看不明白的警告加 error。

这里有一个关键点：Vue 3 + Vite 项目对 Node 版本要求较高。Vite 5 以上通常要求 Node 18+，某些依赖包甚至需要 Node 20。服务器上如果用 apt 直接装的 nodejs，大概率是很老的版本（Ubuntu 22.04 默认源里是 12.x 或 16.x）。所以我建议在服务器上用 nvm 安装 Node，而不是用 apt：

bash复制curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash
source ~/.bashrc
nvm install 20.11.1
nvm use 20.11.1
node -v

如果你只是想在本地构建好再上传 dist，那服务器的 Node 版本暂时可以不关心。但从自动化和后续维护角度看，在服务器上保持一个可复现的构建环境也是一种好习惯。

构建完成后，产物是项目根目录下的 dist 文件夹。你需要做的不是把整个前端源代码传上去，而是只传 dist 这个静态资源目录。这是很多新手会搞混的点——把 node_modules、src、public 一股脑传上去完全没有必要，还会拖慢传输速度、占用服务器空间。

上传方式依然可以是 scp：

bash复制scp -r dist deploy@你的公网IP:/var/www/myapp/

为了让后续更新时旧文件不残留，执行上传前先在服务器上清空目录：

bash复制sudo rm -rf /var/www/myapp/*

4.3 路由 history 模式的两个大坑

Vue 3 默认的 createWebHistory 函数生成的是 HTML5 History 模式路由，URL 看起来像 https://example.com/dashboard，很干净。但问题随之而来：当用户直接访问 https://example.com/dashboard 时，Nginx 会先去磁盘上找有没有 dashboard 这个文件，找不到就直接 404。

本地开发时你感觉不到这个问题，因为一切由 Vite 的开发服务器接管了，它会把所有路径退回给 index.html。部署到 Nginx 后，如果没做额外配置，一刷新非首页就会白屏或 404。

解决方式有两种。第一种是后端兜底，把未知路径全转发到 index.html（需要 Spring Boot 自己处理转发）；第二种是 Nginx 配置 try_files 指令，这也是绝大多数项目采用的方案。关于具体配置我放在第 5 节 Nginx 实战部分一并给出，那里才是整个部署链路最见功力的地方。

还有一个容易忽略的坑：如果你的 Vue 项目最终通过域名二级目录访问，比如 https://example.com/myapp/，那 history 路由配置会非常痛苦，不仅要设置 base 为 /myapp/，Nginx 的 try_files 和静态资源路径也都要跟着变。个人项目强烈建议要么直接买一个域名解析根路径，要么用子域名如 app.example.com，不要用子路径部署 Vue 项目，能省掉一大半路由问题。

5. Nginx 反向代理：这才是把前后端缝合起来的关键角色

5.1 安装 Nginx 以及它为什么必须存在

先明确一个架构问题：前后端分离的项目部署后，浏览器访问过程是这样的——用户在地址栏输入域名，DNS 解析到 ECS 的公网 IP，流量到达 Nginx（监听 80/443 端口），Nginx 根据请求路径分流：如果访问的是 /、/login、/dashboard 这种页面路由，它就把静态文件（前端 dist 里的内容）直接返回；如果请求的是 /api/xxx 这种接口地址，它就作为反向代理把请求转发给本机 8080 端口跑着的 Spring Boot 进程。

所以 Nginx 不是锦上添花，而是这个架构里的咽喉要道。

安装方式：

bash复制sudo apt update
sudo apt install -y nginx

安装后，Nginx 会启动并监听 80 端口。你在浏览器直接访问服务器公网 IP，会看到 Nginx 的欢迎页。这是很好的健康检查信号，说明 80 端口通了。此时我们先用 curl 检查一下：

bash复制curl -I http://localhost

如果看到 HTTP/1.1 200 的响应，Nginx 就绪。

5.2 一份可以直接抄的站点配置

Nginx 的配置入口是 /etc/nginx/nginx.conf，但它通过 include 指令加载 /etc/nginx/sites-enabled/ 下所有文件。标准做法是在 sites-available 里新建配置文件，再软链接到 sites-enabled 启用站点。

一个典型的 Spring Boot + Vue 部署站点配置长这样：

nginx复制server {
    listen 80;
    server_name yourdomain.com;  # 换成你的域名或公网IP

    root /var/www/myapp;
    index index.html;

    # 前端页面路由：找不到对应文件时都退回 index.html
    location / {
        try_files $uri $uri/ /index.html;
    }

    # 后端接口前缀：反向代理到 Spring Boot
    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;
    }

    # 静态资源缓存策略：js/css/img 这类文件带哈希指纹，可以缓存很久
    location /static/ {
        expires 7d;
        add_header Cache-Control "public";
    }
}

把这段配置里的 yourdomain.com 替换成你的实际域名，如果还没有域名，可以临时用公网 IP 替代，注意 IP 方式访问时 server_name 可以留空或不匹配，但强烈建议尽快绑定域名。这里的几个关键点都必须理解：

try_files $uri $uri/ /index.html; 是处理 Vue history 路由回退的灵魂。它的逻辑是：先找和请求路径同名的真实文件，比如有 /static/js/app.js 就返回；找不到就找同名目录；再找不到就返回 /index.html。这样无论你的路由多深，用户刷新都不会 404。

location /api/ 和 proxy_pass http://127.0.0.1:8080; 组成反向代理。这里有一个容易踩坑的细节：proxy_pass 的 URI 是否带尾斜杠，行为完全不同。如果 proxy_pass 不带 URI（也就是写 http://127.0.0.1:8080;），它会把原始请求的完整 URI 原封不动转发给后端；如果后面带了路径如 http://127.0.0.1:8080/，则会把 location 前缀匹配到的 /api 部分替换掉。大多数情况下，你的 Spring Boot 接口映射本身就带着 /api 前缀，比如 @RequestMapping("/api/user")，所以就不需要在 proxy_pass 里做路径改写，保持不带 URI 的写法就好。

写完配置后执行：

bash复制sudo ln -s /etc/nginx/sites-available/myapp /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx

nginx -t 会先做语法检查，看到 syntax is ok 再重启或 reload。这一步养成习惯，能让你省掉无数次因为少打一个分号导致整个服务挂掉的尴尬。

5.3 部署完成后最常见的排查链路

配置完成后，把访问链路在脑子里过一遍，排查起来就会有条理得多：

访问 http://你的IP/ 白屏，打开 F12 看 Console 报错：如果是 404 并且指向 js/css 文件，多半是静态资源路径不对或 dist 没传到 root 目录；如果页面渲染但接口全挂，看 Network 里请求的接口地址是否以 /api 开头。
访问 http://你的IP/api/ping 返回 404 或 502。404 说明请求到了 Nginx 但没转发成功，可能是 Spring Boot 接口本身没有 /api 前缀；502 说明 Nginx 尝试连接 127.0.0.1:8080 但后端进程没起来或端口不对。
刷新某页面白屏，其他页面正常。几乎可以断定是 try_files 没生效，去检查 Nginx location / 配置。

排查时最有用的命令是这两个：

bash复制# 实时查看 Nginx 访问日志和错误日志
sudo tail -f /var/log/nginx/access.log
sudo tail -f /var/log/nginx/error.log

# 查看后端日志
journalctl -u myapp -f

通过日志定位问题，是运维的核心能力。怕就怕你只看浏览器端一个 "404" 就开始瞎猜改配置，越改越乱。

6. 用 systemd 托管 Spring Boot 进程：让服务崩溃自动重启

6.1 写一个 myapp.service 文件

手工用 java -jar 启动的后端进程有几个致命弱点：SSH 断开后进程未必会立刻死，但服务器一旦重启它就不会自动拉起；进程意外崩溃后也没有自动重启机制。正确的生产态是使用 systemd。它本身是 Linux 标准的服务管理工具，Ubuntu 16.04+ 都在使用。

进入 systemd 配置目录，创建一个服务文件：

bash复制sudo vim /etc/systemd/system/myapp.service

内容如下：

ini复制[Unit]
Description=My Spring Boot Application
After=network.target mysql.service

[Service]
User=deploy
Group=deploy
WorkingDirectory=/opt/myapp
ExecStart=/usr/bin/java -Xms256m -Xmx512m -jar /opt/myapp/myapp.jar --spring.profiles.active=prod
Restart=on-failure
RestartSec=10
StandardOutput=journal
StandardError=journal
Environment=JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64

[Install]
WantedBy=multi-user.target

解释几个容易出错的点：

ExecStart 里的 Java 路径最好写全。你可以通过 which java 查到路径，常见的是 /usr/local/java/bin/java 或 /usr/bin/java。直接写 java -jar 某些情况下 systemd 会因为 PATH 环境不同找不到可执行文件，报错信息非常隐晦。

-Xms256m -Xmx512m 是 JVM 堆内存参数。-Xms 是最小堆，-Xmx 是最大堆。个人项目对内存没那么大需求，512MB 的上限已经能承担不小并发，给操作系统留足余量才不会导致整机 swap 频繁、卡到没法 SSH。

Restart=on-failure 配合 RestartSec=10，能让进程挂掉后 10 秒自动重启。这个配置应对偶发内存溢出或外部依赖短时抖动非常有效。

After=network.target mysql.service 明确了启动顺序：如果系统里装了 MySQL 服务，应该等 MySQL 起来了再启动我们的应用。否则 Spring Boot 启动时如果数据库还没起来，数据源初始化失败会导致启动报错。

启用并启动服务：

bash复制sudo systemctl daemon-reload
sudo systemctl enable myapp
sudo systemctl start myapp

enable 会让服务在服务器开机时自动拉起。到这里，后端进程才真正有了"系统级公民"的身份。

6.2 查看状态日志，以及如何优雅重启

运维中高频操作就是查日志和重启。常用的命令集：

bash复制# 查看服务整体状态
sudo systemctl status myapp

# 查看最近 100 行日志
sudo journalctl -u myapp -n 100

# 持续跟踪日志
sudo journalctl -u myapp -f

# 重启服务
sudo systemctl restart myapp

需要注意 systemd 的日志是二进制的，journalctl 是它的阅读器。如果你想把日志输出到文件做持久化，可以在 Service 段这么配置：

ini复制StandardOutput=append:/opt/myapp/logs/out.log
StandardError=append:/opt/myapp/logs/err.log

但更推荐的做法是先让它输出到 journal，配合 journalctl 查看。日志文件如果没做好 logrotate，日积月累会有涨满磁盘的风险，journal 则本身自带大小和轮转策略。

上传新版本 jar 的完整发布流程应该是：

bash复制sudo systemctl stop myapp
sudo cp /opt/myapp/myapp.jar /opt/myapp/myapp.jar.bak
sudo mv 新上传的jar /opt/myapp/myapp.jar
sudo systemctl start myapp
sudo systemctl status myapp

先备份旧包再覆盖，万一新包启动失败可以一分钟回滚。这个习惯在正式环境能救命。

6.3 MySQL 等中间件的部署顺序

如果你项目中还要用到 MySQL 或 Redis，请先装好它们并把端口监听在 127.0.0.1，再启动 Spring Boot。数据库和缓存这类有状态中间件，我个人建议不要和业务 jar 部署在同一台机器的同一个目录，但它们作为单机版项目部署在同一台 ECS 上完全可行。

安装 MySQL 后有一件灰常容易忽略的事：MySQL 默认只监听 127.0.0.1，如果你的 Spring Boot 配置里数据库地址写的也是 127.0.0.1，那没问题；如果你把数据库地址改成了服务器内网 IP 或 0.0.0.0，就会遇到连不上或权限拒绝的问题。在单机部署场景，数据库地址和 Redis 地址统一写 127.0.0.1 是最稳妥的。

MySQL 建库建用户时，尽量避免直接用 root 连业务库。习惯性创建一个最小权限账户：

sql复制CREATE DATABASE myapp DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'myapp'@'localhost' IDENTIFIED BY '强密码';
GRANT ALL PRIVILEGES ON myapp.* TO 'myapp'@'localhost';
FLUSH PRIVILEGES;

这样即使配置文件泄露，攻击者也拿不到整个数据库的管理权限。

7. 后续值得做的几件事：HTTPS、基础优化和一次完整验证

7.1 域名解析与 HTTPS 证书：尽快把 IP 访问升级为域名访问

如果你只是在浏览器输入 IP 访问，你会发现很多高级特性没法用（比如 Cookie 的 Secure 标志、部分浏览器 API 需要安全上下文）。所以做任何认真交付之前，都建议把域名和 HTTPS 安排上。

域名解析不用多解释，在阿里云控制台加一条 A 记录，把 app.yourdomain.com 指向 ECS 公网 IP。等 DNS 生效后，把 Nginx 配置里所有 server_name 改成域名，重新 reload。

HTTPS 证书方面，免费且最省心的是使用 Let's Encrypt 签发的证书，阿里云也有免费的 DV 证书可以申请，但每年需要手动续期。在 Ubuntu 上装 certbot 并配合 Nginx 插件，能实现一条命令签发证书并自动修改 Nginx 配置：

bash复制sudo apt install -y certbot python3-certbot-nginx
sudo certbot --nginx -d yourdomain.com

Certbot 会自动检查 80 端口上 Nginx 的 server_name，然后完成证书签发，并重载配置使 443 生效。之后自动续期任务系统会通过 systemd timer 默认配好，你几乎不需要关心。

有了证书后，可以在 Nginx 的 80 端口 server 中加入跳转：

nginx复制server {
    listen 80;
    server_name yourdomain.com;
    return 301 https://$host$request_uri;
}

这样所有 HTTP 请求都会自动升级到 HTTPS。

7.2 验证一条完整访问链路

项目部署后，建议写一个验证清单，按顺序走一遍，用最少的成本确认整个系统正常：

bash复制# 1. 后端进程存活
sudo systemctl status myapp

# 2. 后端接口本地正常
curl http://127.0.0.1:8080/api/ping

# 3. Nginx 配置正常
sudo nginx -t

# 4. Nginx 代理转发正常
curl http://127.0.0.1/api/ping

# 5. 前端首页正常
curl -I http://127.0.0.1/

# 6. 浏览器访问域名
浏览器打开 https://yourdomain.com

任何一步失败就停在当前步骤排查，不要继续往下走。几乎所有的部署问题都能通过这个递增链路在 10 分钟内定位到具体环节。

7.3 从"能跑"到"跑得舒服"：几个优先级很高的优化

部署完不等于项目就完美了，虽然这篇主要讲"从零到一"，但有几个小优化做起来的性价比极高，顺手就能完成：

给静态资源加缓存策略：在 Nginx 的 location /static/ 里加 expires 指令，前端构建产生的带 hash 文件名资源可以缓存很久，页面重复加载速度会快很多。如果项目不存在老用户缓存错乱问题，可以放心地把缓存时间调到 7 天甚至更长。

为 Spring Boot 打包时开启 Spring Boot 的优雅停机。在 application-prod.yml 里加：

yaml复制server:
  shutdown: graceful

这样重启服务时，正在处理的请求会被等待完成，而不是被直接掐断。对有真实用户的场景体验差异非常明显。

定时备份数据库和配置文件：用 cron 加一行脚本，每天凌晨用 mysqldump 导出线上库到一个备份目录，保留最近 7 天即可。个人项目不会要求完整备份体系，但"意外删库跑路"的阴影，只需要一行定时任务就能基本驱散。

我最初自己学部署时，最大的感受是：网上教程很多都只教你"敲什么"，却很少告诉你"为什么敲"。这导致一旦报错，整个人就懵了。所以这篇尽量把每个环节背后的原因拆开讲。你照着完整走一遍，之后如果再遇到部署类问题，心态会完全不一样——因为你不是在背命令，而是真正理解了这条数据链路从浏览器到 Nginx、从静态文件到后端进程的每一次流转。

我自己踩过比较深的一个坑，是做完所有配置后，浏览器一直显示 502，查了很久才发现 Spring Boot 因为数据库没启动导致启动失败，而 systemd 里配置的 Restart=on-failure 会让它一遍遍重启，进程始终处于"启动中"状态。希望你在做的时候，每个环节都确认前一步真的通了再往下走，部署这件事，慢就是快。