企业官网建设流程全解析

1. 从一次真实的部署翻车说起

上个月帮一个朋友排查线上问题，场景很典型：他在本地用 IDEA 跑得好好的 Spring Boot 服务，打成 jar 包往服务器上一扔，java -jar一执行，日志刷了两屏就停了，接口全部 502。他第一反应是“代码有 bug”，折腾了一下午才发现，是生产环境的 JDK 版本和本地不一致，加上配置文件里的数据库连接池参数在低配机器上直接被打满。这类问题几乎每个后端都踩过，跟代码质量没半点关系，纯粹是“本地能跑”和“生产能扛”之间的鸿沟。

这篇内容就围绕IDEA 构建 Spring Boot 项目并部署到生产环境这条完整链路展开。我会把从项目初始化、依赖管理、打包方式选择、配置文件分层、启动脚本编写，到进程守护、日志切割、常见故障排查的整套流程拆开讲透。适合刚接触 Spring Boot 部署的同学，也适合已经能跑通但总在线上翻车的朋友——很多细节文档里不会写，但生产环境会狠狠教你。

需要先明确一个认知：部署不是“把 jar 传上去”这一个动作，而是一套可重复、可回滚、可观测的工程流程。下面所有内容都围绕这个目标来组织。

2. 项目初始化与依赖管理的关键决策

2.1 用 IDEA 创建项目时那几个容易选错的选项

在 IDEA 里新建 Spring Boot 项目，走 Spring Initializr 是最顺手的路径。但有几个选项新手特别容易随手一点，后面埋雷。

打包方式（Packaging）：默认给的是 Jar，这个对绝大多数场景是对的。War 只在需要部署到外部 Servlet 容器（比如老式 Tomcat）时才用。现在主流是内嵌 Tomcat + Jar，一条java -jar就能起，运维成本低。除非你们公司有历史遗留的容器规范，否则别选 War。

Java 版本：这里必须和生产服务器的 JDK 版本对齐。我见过太多人本地用 JDK 17，服务器上装的是 JDK 8，结果 class 文件版本不兼容，启动直接报UnsupportedClassVersionError。选之前先登录服务器敲一句java -version，以那个为准。如果服务器还没定，那就选一个 LTS 版本（8、11、17、21），全链路统一。

依赖选择：Spring Web、Lombok、Spring Boot DevTools 这几个是常用的。但要注意DevTools 绝对不能进生产包，它会在打包时触发额外的重启机制，还会拖慢启动。正确做法是把它设为optional或者用 Maven 的providedscope，后面会讲怎么在打包时排除。

2.2 Maven 与 Gradle 的取舍逻辑

IDEA 两个都支持，选哪个不是信仰问题，是团队协作问题。

我的建议很直接：中小团队、以业务开发为主，选 Maven。它的pom.xml虽然啰嗦，但胜在稳定、可预测，谁来看都懂。Gradle 更适合多模块、构建逻辑复杂、对构建速度敏感的场景。别为了“先进”而选 Gradle，最后构建脚本写得比业务代码还复杂，得不偿失。

2.3 依赖版本锁定：别让“自动升级”坑了你

Spring Boot 的 parent 已经帮我们管理了大部分依赖版本，这是好事。但有个坑：如果你手动引入了 parent 没管理的依赖，一定要显式写版本号，否则 Maven 会按自己的规则挑一个，可能和 Spring Boot 的版本冲突。

更稳妥的做法是用dependencyManagement统一锁定，或者在pom.xml里用<properties>集中管理版本变量。我习惯把所有第三方版本号抽到 properties 里，升级时改一处即可，避免版本散落各处导致“这个模块升了那个没升”的诡异问题。

提示：执行mvn dependency:tree可以打印完整依赖树，排查冲突时这是第一把武器。看到同一个库出现多个版本，就要警惕了。

3. 配置文件分层与环境隔离

3.1 为什么不能只有一个 application.yml

新手最常见的做法是：所有配置写在一个application.yml里，本地改改数据库地址就提交，部署时再手动改服务器上的文件。这套流程在单人项目里勉强能用，一旦多人协作或环境变多，必然出事——要么把生产密码提交进了 Git，要么改错环境连了测试库。

正确姿势是按环境拆分配置文件：

• application.yml：放通用配置，不含任何环境敏感信息
• application-dev.yml：开发环境
• application-test.yml：测试环境
• application-prod.yml：生产环境

然后在主配置里用spring.profiles.active指定激活哪个。启动时可以通过命令行参数覆盖，这是关键：

java -jar app.jar --spring.profiles.active=prod

这样同一个 jar 包可以部署到任意环境，配置通过外部注入，符合“一次构建，多处部署”的原则。

3.2 敏感配置绝不进代码仓库

数据库密码、Redis 密码、第三方密钥，这些东西绝对不能硬编码在 yml 里提交到 Git。哪怕仓库是私有的也不行，历史记录一旦泄露就是永久泄露。

几种可行方案，按推荐度排序：

1. 环境变量注入：配置里写${DB_PASSWORD}，启动脚本里 export 或通过 systemd 的 Environment 传入。最干净，容器化场景首选。
2. 外部配置文件：把application-prod.yml放在服务器固定目录，启动时用--spring.config.location指定。jar 包里不含敏感信息。
3. 配置中心：规模大了之后用 Nacos、Apollo 这类统一管理，支持动态刷新。但小项目没必要上，增加运维复杂度。

我一般用方案 1 和 2 结合：通用配置在 jar 内，敏感项走环境变量。启动脚本里集中管理，一目了然。

3.3 生产环境必须调整的几个参数

默认配置是给开发用的，直接上生产会出问题。下面这几个参数我每次部署都会检查：

server: port: 8080 tomcat: threads: max: 200 # 默认 200，高并发可调大，但要配合机器核数 min-spare: 20 accept-count: 100 # 等待队列长度 max-connections: 8192 spring: datasource: hikari: maximum-pool-size: 20 # 不是越大越好，参考公式：核数*2+磁盘数 minimum-idle: 5 connection-timeout: 30000 idle-timeout: 600000 max-lifetime: 1800000 # 必须小于数据库的 wait_timeout

连接池大小这里展开说一句：很多人以为越大越好，其实连接数超过数据库处理能力反而会拖垮它。经验公式是CPU核数 * 2 + 有效磁盘数。4 核机器配 10 到 20 就够，具体要压测验证。max-lifetime一定要小于数据库服务端的连接超时时间，否则会拿到已被服务端关闭的死连接，报Communications link failure。

4. 打包方式与产物优化

4.1 三种打包方式的适用场景

Spring Boot 打包主要有三种形态，选错了要么启动慢，要么部署麻烦。

第一种：可执行 Jar（推荐）。mvn clean package出来的就是，内嵌 Tomcat，java -jar直接跑。优点是简单、自包含、跨平台。缺点是 jar 包体积大（几十 MB 起），每次改一行代码都要重新打整个包。

第二种：分层 Jar（Layered Jar）。Spring Boot 2.3 之后支持，把依赖、快照、应用代码分成不同层。配合 Docker 构建时，依赖层不变就能复用缓存，大幅加快镜像构建。容器化部署强烈推荐。

第三种：War 包。部署到外部 Tomcat。除非有硬性要求，否则不推荐，失去了 Spring Boot 内嵌容器的所有便利。

4.2 用 Maven 插件精简产物

默认打包会把测试代码、DevTools 都塞进去。用spring-boot-maven-plugin配合配置可以瘦身：

<build> <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> <configuration> <excludes> <exclude> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> </exclude> </excludes> </configuration> </plugin> </plugins> </build>

Lombok 只在编译期起作用，运行时不需要，排除掉能省一点体积。DevTools 同理，用providedscope 声明它就不会被打进包。

打包命令建议加上跳过测试，除非你的 CI 流程里单独跑测试：

mvn clean package -DskipTests

注意：-DskipTests是编译测试代码但不执行，-Dmaven.test.skip=true是连编译都跳过。生产打包用前者更稳妥，至少能发现测试代码的编译错误。

4.3 分层打包的具体配置

如果走容器化路线，分层打包值得配置。在pom.xml里加：

<plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> <configuration> <layers> <enabled>true</enabled> </layers> </configuration> </plugin>

打包后用java -Djarmode=layertools -jar app.jar list可以看到分层结构，通常分为 dependencies、spring-boot-loader、snapshot-dependencies、application 四层。写 Dockerfile 时按层 COPY，依赖不变时镜像构建能快好几倍。

5. 生产环境部署实操全流程

5.1 服务器环境准备清单

拿到一台干净的服务器，部署前先过一遍这个清单，缺一样后面都可能卡住：

• JDK：版本与本地一致，java -version确认
• 目录规划：我习惯用/opt/app/放 jar，/opt/app/logs/放日志，/opt/app/config/放外部配置
• 专用用户：别用 root 跑应用，建一个appuser，权限最小化
• 时区：timedatectl确认是Asia/Shanghai，否则日志时间对不上排查很痛苦
• 文件句柄数：ulimit -n至少 65535，高并发下默认 1024 会报Too many open files
• 防火墙：确认端口放行，但别用systemctl stop firewalld这种粗暴做法

5.2 上传与启动：一个可复用的启动脚本

别每次手敲java -jar，写个脚本，参数集中管理：

#!/bin/bash APP_NAME="myapp" JAR_PATH="/opt/app/${APP_NAME}.jar" LOG_PATH="/opt/app/logs" JAVA_OPTS="-Xms512m -Xmx1024m -XX:+UseG1GC -XX:MaxGCPauseMillis=200" JAVA_OPTS="${JAVA_OPTS} -Dfile.encoding=UTF-8 -Duser.timezone=Asia/Shanghai" PID=$(ps -ef | grep ${JAR_PATH} | grep -v grep | awk '{print $2}') start() { if [ -n "${PID}" ]; then echo "${APP_NAME} already running, pid=${PID}" return fi nohup java ${JAVA_OPTS} -jar ${JAR_PATH} \ --spring.profiles.active=prod \ > ${LOG_PATH}/console.log 2>&1 & echo "${APP_NAME} started" } stop() { if [ -z "${PID}" ]; then echo "${APP_NAME} not running" return fi kill ${PID} sleep 5 if [ -n "$(ps -p ${PID} -o pid=)" ]; then kill -9 ${PID} fi echo "${APP_NAME} stopped" } case "$1" in start) start ;; stop) stop ;; restart) stop; start ;; *) echo "Usage: $0 {start|stop|restart}" ;; esac

几个参数解释一下。-Xms和-Xmx设成一样，避免运行期堆伸缩带来的抖动。G1 是 JDK 9 之后的默认收集器，JDK 8 上手动指定。MaxGCPauseMillis是目标停顿时间，不是硬保证，但给 GC 一个方向。-Duser.timezone显式指定时区，比依赖系统设置更可靠。

提示：nohup加&只是让进程在后台跑，它不会在服务器重启后自动拉起。真正的生产环境要用 systemd 或 supervisor 做进程守护，见下一节。

5.3 用 systemd 做进程守护

nohup的进程一旦服务器重启就没了，而且崩溃后不会自动重启。systemd 是 Linux 上最标准的方案，配置一次省心很久。

在/etc/systemd/system/myapp.service写入：

[Unit] Description=My Spring Boot Application After=network.target [Service] Type=simple User=appuser WorkingDirectory=/opt/app Environment="DB_PASSWORD=your_password" Environment="JAVA_HOME=/usr/lib/jvm/java-17" ExecStart=/usr/bin/java -Xms512m -Xmx1024m -jar /opt/app/myapp.jar --spring.profiles.active=prod SuccessExitStatus=143 Restart=on-failure RestartSec=10 StandardOutput=append:/opt/app/logs/console.log StandardError=append:/opt/app/logs/console.log [Install] WantedBy=multi-user.target

SuccessExitStatus=143是因为 Java 进程收到 SIGTERM（信号 15）退出时返回码是 143，不声明的话 systemd 会认为是异常退出。Restart=on-failure配合RestartSec=10实现崩溃后 10 秒自动重启，这是生产环境的基本保障。

启用流程：

systemctl daemon-reload systemctl enable myapp systemctl start myapp systemctl status myapp

enable是关键，它让服务开机自启。很多人只start不enable，重启服务器后服务没起来，一脸懵。

5.4 日志管理：别让日志撑爆磁盘

Spring Boot 默认只往控制台输出，生产环境必须落盘并切割。在application-prod.yml里配置 Logback：

logging: file: name: /opt/app/logs/myapp.log logback: rollingpolicy: max-file-size: 100MB max-history: 30 total-size-cap: 5GB level: root: info com.example: debug

max-file-size单文件上限，max-history保留天数，total-size-cap总容量上限。三个一起用才能防止磁盘被写满。我见过只配了max-history没配total-size-cap的，某天日志量暴涨，一天写了 50GB，磁盘直接爆掉。

如果日志量特别大，建议接入 ELK 或 Loki 这类集中式日志系统，本地只保留最近几天。排查问题时用grep配合时间范围过滤，比翻文件高效得多。

6. 常见故障与排查技巧实录

6.1 启动失败类问题速查

6.2 一个真实的排查案例

有次线上服务每隔几小时就假死一次，接口超时但进程还在。看日志没有异常，CPU 也不高。最后用jstack抓线程栈，发现大量线程卡在数据库连接获取上，HikariPool等待超时。

根因是max-lifetime设成了 30 分钟，而数据库服务端的wait_timeout是 10 分钟。连接在池子里放了 10 分钟就被服务端单方面关闭了，应用却以为它还活着，拿到的全是死连接。把max-lifetime调到小于wait_timeout后问题消失。

这个坑的教训是：连接池参数必须和数据库服务端参数联动看，不能只盯着应用侧。排查这类问题，jstack和jstat是必备工具，光看日志往往看不出所以然。

6.3 部署后接口 404 或 500 的定位思路

先分清是应用没起来还是路由问题。curl localhost:8080/actuator/health探一下，如果健康检查通，说明应用活着，问题在具体接口。这时候按顺序查：

1. 上下文路径：有没有配server.servlet.context-path，访问时漏了前缀
2. Profile 是否生效：日志开头会打印The following profiles are active: prod，确认一下
3. 接口路径大小写：Linux 对路径大小写敏感，本地 Windows 不敏感，容易漏
4. 依赖服务：500 多半是下游挂了，看异常栈定位

提示：生产环境一定要开actuator的健康检查端点，但只暴露 health 和 info，别把 env、beans 这些敏感端点暴露出去，否则等于把内部结构送给别人。

6.4 几个我踩过的坑

坑一：配置文件优先级搞反。Spring Boot 的配置优先级是：命令行参数 > 外部 config 目录 > jar 内 config > jar 内根目录。有次我把生产配置放在 jar 内，又用命令行传了参数，结果命令行覆盖了文件，排查半天。记住这个顺序能省很多时间。

坑二：nohup输出重定向写错。> log 2>&1和2>&1 > log效果完全不同，后者错误输出还是打到终端。顺序必须是先重定向标准输出，再把标准错误指向标准输出。

坑三：忘了改文件权限。用appuser跑服务，但 jar 和日志目录属主是 root，启动时报Permission denied。上传后记得chown -R appuser:appuser /opt/app。

坑四：时区不一致导致定时任务错乱。应用时区、数据库时区、服务器时区三者不一致，@Scheduled任务执行时间全乱。统一设成Asia/Shanghai，数据库连接串里也加上serverTimezone。

7. 上线前的检查清单与回滚预案

部署这件事，准备得越充分，出事时越从容。我每次上线前都会过一遍这个清单：

• jar 包 MD5 校验，确认上传完整
• 生产配置文件已就位，敏感项走环境变量
• 数据库脚本已执行，且可回滚
• 端口、防火墙、时区、句柄数已确认
• 启动脚本和 systemd 服务已配置
• 日志切割策略已生效
• 健康检查端点可访问
• 旧版本 jar 已备份，回滚命令已准备好

回滚方案要具体到命令。最简单的做法是保留上一个版本的 jar，出问题时停服务、换 jar、启服务，三步搞定。如果数据库有变更，回滚脚本也要提前写好并测试过。没测试过的回滚方案等于没有方案，这句话我深有体会。

最后分享一个习惯：每次部署后，别急着走，盯五分钟日志，看有没有异常堆栈、有没有慢查询、内存有没有异常增长。这五分钟能拦住大部分“上线即故障”的情况。部署不是终点，稳定运行才是。