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 两个都支持选哪个不是信仰问题是团队协作问题。维度MavenGradle学习曲线平缓XML 直观陡峭Groovy/Kotlin DSL构建速度中等增量构建快大项目优势明显生态成熟度极高插件海量高但部分老插件缺失可读性配置冗长但清晰简洁但灵活过头易失控团队协作新人上手快需要统一规范我的建议很直接中小团队、以业务开发为主选 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.activeprod这样同一个 jar 包可以部署到任意环境配置通过外部注入符合“一次构建多处部署”的原则。3.2 敏感配置绝不进代码仓库数据库密码、Redis 密码、第三方密钥这些东西绝对不能硬编码在 yml 里提交到 Git。哪怕仓库是私有的也不行历史记录一旦泄露就是永久泄露。几种可行方案按推荐度排序环境变量注入配置里写${DB_PASSWORD}启动脚本里 export 或通过 systemd 的 Environment 传入。最干净容器化场景首选。外部配置文件把application-prod.yml放在服务器固定目录启动时用--spring.config.location指定。jar 包里不含敏感信息。配置中心规模大了之后用 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出来的就是内嵌 Tomcatjava -jar直接跑。优点是简单、自包含、跨平台。缺点是 jar 包体积大几十 MB 起每次改一行代码都要重新打整个包。第二种分层 JarLayered Jar。Spring Boot 2.3 之后支持把依赖、快照、应用代码分成不同层。配合 Docker 构建时依赖层不变就能复用缓存大幅加快镜像构建。容器化部署强烈推荐。第三种War 包。部署到外部 Tomcat。除非有硬性要求否则不推荐失去了 Spring Boot 内嵌容器的所有便利。4.2 用 Maven 插件精简产物默认打包会把测试代码、DevTools 都塞进去。用spring-boot-maven-plugin配合配置可以瘦身build plugins plugin groupIdorg.springframework.boot/groupId artifactIdspring-boot-maven-plugin/artifactId configuration excludes exclude groupIdorg.projectlombok/groupId artifactIdlombok/artifactId /exclude /excludes /configuration /plugin /plugins /buildLombok 只在编译期起作用运行时不需要排除掉能省一点体积。DevTools 同理用providedscope 声明它就不会被打进包。打包命令建议加上跳过测试除非你的 CI 流程里单独跑测试mvn clean package -DskipTests注意-DskipTests是编译测试代码但不执行-Dmaven.test.skiptrue是连编译都跳过。生产打包用前者更稳妥至少能发现测试代码的编译错误。4.3 分层打包的具体配置如果走容器化路线分层打包值得配置。在pom.xml里加plugin groupIdorg.springframework.boot/groupId artifactIdspring-boot-maven-plugin/artifactId configuration layers enabledtrue/enabled /layers /configuration /plugin打包后用java -Djarmodelayertools -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_NAMEmyapp JAR_PATH/opt/app/${APP_NAME}.jar LOG_PATH/opt/app/logs JAVA_OPTS-Xms512m -Xmx1024m -XX:UseG1GC -XX:MaxGCPauseMillis200 JAVA_OPTS${JAVA_OPTS} -Dfile.encodingUTF-8 -Duser.timezoneAsia/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.activeprod \ ${LOG_PATH}/console.log 21 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] DescriptionMy Spring Boot Application Afternetwork.target [Service] Typesimple Userappuser WorkingDirectory/opt/app EnvironmentDB_PASSWORDyour_password EnvironmentJAVA_HOME/usr/lib/jvm/java-17 ExecStart/usr/bin/java -Xms512m -Xmx1024m -jar /opt/app/myapp.jar --spring.profiles.activeprod SuccessExitStatus143 Restarton-failure RestartSec10 StandardOutputappend:/opt/app/logs/console.log StandardErrorappend:/opt/app/logs/console.log [Install] WantedBymulti-user.targetSuccessExitStatus143是因为 Java 进程收到 SIGTERM信号 15退出时返回码是 143不声明的话 systemd 会认为是异常退出。Restarton-failure配合RestartSec10实现崩溃后 10 秒自动重启这是生产环境的基本保障。启用流程systemctl daemon-reload systemctl enable myapp systemctl start myapp systemctl status myappenable是关键它让服务开机自启。很多人只start不enable重启服务器后服务没起来一脸懵。5.4 日志管理别让日志撑爆磁盘Spring Boot 默认只往控制台输出生产环境必须落盘并切割。在application-prod.yml里配置 Logbacklogging: 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: debugmax-file-size单文件上限max-history保留天数total-size-cap总容量上限。三个一起用才能防止磁盘被写满。我见过只配了max-history没配total-size-cap的某天日志量暴涨一天写了 50GB磁盘直接爆掉。如果日志量特别大建议接入 ELK 或 Loki 这类集中式日志系统本地只保留最近几天。排查问题时用grep配合时间范围过滤比翻文件高效得多。6. 常见故障与排查技巧实录6.1 启动失败类问题速查现象大概率原因排查方向UnsupportedClassVersionErrorJDK 版本不匹配对比本地和服务器java -versionPort already in use端口被占用lsof -i:8080找占用进程Communications link failure数据库连不上或连接池配置错检查网络、账号、max-lifetime启动卡住无日志配置加载阻塞或 DNS 解析慢加-Djava.net.preferIPv4StacktrueOutOfMemoryError堆内存不足调大-Xmx用jmap分析堆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探一下如果健康检查通说明应用活着问题在具体接口。这时候按顺序查上下文路径有没有配server.servlet.context-path访问时漏了前缀Profile 是否生效日志开头会打印The following profiles are active: prod确认一下接口路径大小写Linux 对路径大小写敏感本地 Windows 不敏感容易漏依赖服务500 多半是下游挂了看异常栈定位提示生产环境一定要开actuator的健康检查端点但只暴露 health 和 info别把 env、beans 这些敏感端点暴露出去否则等于把内部结构送给别人。6.4 几个我踩过的坑坑一配置文件优先级搞反。Spring Boot 的配置优先级是命令行参数 外部 config 目录 jar 内 config jar 内根目录。有次我把生产配置放在 jar 内又用命令行传了参数结果命令行覆盖了文件排查半天。记住这个顺序能省很多时间。坑二nohup输出重定向写错。 log 21和21 log效果完全不同后者错误输出还是打到终端。顺序必须是先重定向标准输出再把标准错误指向标准输出。坑三忘了改文件权限。用appuser跑服务但 jar 和日志目录属主是 root启动时报Permission denied。上传后记得chown -R appuser:appuser /opt/app。坑四时区不一致导致定时任务错乱。应用时区、数据库时区、服务器时区三者不一致Scheduled任务执行时间全乱。统一设成Asia/Shanghai数据库连接串里也加上serverTimezone。7. 上线前的检查清单与回滚预案部署这件事准备得越充分出事时越从容。我每次上线前都会过一遍这个清单jar 包 MD5 校验确认上传完整生产配置文件已就位敏感项走环境变量数据库脚本已执行且可回滚端口、防火墙、时区、句柄数已确认启动脚本和 systemd 服务已配置日志切割策略已生效健康检查端点可访问旧版本 jar 已备份回滚命令已准备好回滚方案要具体到命令。最简单的做法是保留上一个版本的 jar出问题时停服务、换 jar、启服务三步搞定。如果数据库有变更回滚脚本也要提前写好并测试过。没测试过的回滚方案等于没有方案这句话我深有体会。最后分享一个习惯每次部署后别急着走盯五分钟日志看有没有异常堆栈、有没有慢查询、内存有没有异常增长。这五分钟能拦住大部分“上线即故障”的情况。部署不是终点稳定运行才是。