Spring Boot 项目放进 Docker 看起来只是“打个包再跑起来”，真正容易出问题的却往往是生产配置、容器时区、JVM 参数和数据库初始化这些细节。下面按实际部署顺序把流程重新拆开讲清楚，并结合 Quartz 表结构缺失这一类典型故障，给出可以直接落地的排查依据和处理办法。
部署前先改对配置与打包产物
很多项目本地运行没问题，放到服务器容器里启动就报错，根源通常不是 Docker 本身，而是配置文件仍然保留了本地开发环境的写法。打包前先把生产环境相关配置过一遍，能省掉后面大量排查时间。
检查数据库、Redis 和文件路径
打开 application-prod.yml（或 application.yml），重点看下面几项：
- 数据库 URL：把
localhost改成服务器真实 IP 或数据库服务地址。容器里的localhost指向的是容器自己，不是宿主机上的数据库。 - Redis 地址：同样不要保留本地地址，改成真实可访问的服务地址。
- 文件上传路径：确认是 Linux 路径格式，例如
/app/upload，不要继续使用C:/upload这类 Windows 路径。
在项目根目录打包 JAR
配置确认后，再执行 Maven 打包：
mvn clean package
打包成功后，可以在 target 目录找到生成的 JAR。本文示例文件名为 myproject-admin.jar，后续 Dockerfile 和启动命令都以这个名字为准。
Dockerfile 怎么写，哪些地方最容易忽略
把 JAR 上传到服务器，例如放到 /opt/docker/myproject/，然后在同目录创建 Dockerfile。这一层的目标很明确：选合适的基础镜像、把时区和运行参数处理好，再保证应用能按预期启动。
示例 Dockerfile
# 1. 指定基础镜像
# 选用Eclipse Temurin (JDK 17) Alpine版，体积小，安全性好
FROM eclipse-temurin:17-jre-alpine
# 2. 设置工作目录
WORKDIR /app
# 3. 解决时区问题 (关键步骤)
# Alpine镜像默认时区UTC，需要安装tzdata并配置为上海时区
# 利用Docker缓存机制，将系统依赖安装放在COPY之前
RUN apk add --no-cache tzdata &&
cp /usr/share/zoneinfo/Asia/Shanghai /etc/localtime &&
echo "Asia/Shanghai" > /etc/timezone &&
apk del tzdata
# 4. 拷贝JAR包
COPY myproject-admin.jar .
# 5. 声明服务端口
EXPOSE 8080
# 6. 配置JVM参数
# -Xms/Xmx: 限制堆内存，防止容器OOM
# -Djava.security.egd: 解决Linux下随机数生成阻塞导致启动慢的问题
ENV JAVA_OPTS="-Xms512m -Xmx1024m -Djava.security.egd=file:/dev/./urandom"
# 7. 启动命令
# 使用sh -c启动让环境变量$JAVA_OPTS生效
ENTRYPOINT ["sh", "-c", "java $JAVA_OPTS -jar myproject-admin.jar"]
这份 Dockerfile 的关键点
- 基础镜像：
eclipse-temurin:17-jre-alpine适合只运行 JAR 的场景，镜像体积相对更小。 - 时区处理：Alpine 默认时区通常是 UTC，如果不处理，日志时间、任务调度时间都可能出现偏差。这里通过安装
tzdata并设置为Asia/Shanghai解决。 - JVM 内存参数：通过
-Xms512m -Xmx1024m给堆内存设边界，避免容器内应用无限吃内存，最后被宿主机直接 Kill。 - 启动方式：
ENTRYPOINT ["sh", "-c", "java $JAVA_OPTS -jar myproject-admin.jar"]这一写法是为了让$JAVA_OPTS在启动时真正生效。
镜像构建与容器运行参数怎么配
Dockerfile 准备好后，下一步就是构建镜像并启动容器。这里最值得注意的是容器资源限制和日志目录挂载，它们直接影响线上稳定性和问题定位效率。
构建镜像
在 JAR 包所在目录执行：
docker build -t myproject-server:1.0 .
当终端出现 Successfully built 和 Successfully tagged 时，说明镜像已经构建完成。
按生产思路启动容器
docker run -d --name myproject-app -p 8080:8080 -m 1.5g --cpus 1 --restart=on-failure:5 -v /home/myproject/logs:/app/logs myproject-server:1.0
这些参数分别解决什么问题
-d：让容器在后台运行。-p 8080:8080：把宿主机 8080 端口映射到容器 8080 端口。-m 1.5g：限制容器最大内存为 1.5G。因为 JVM 堆已经设到 1G，还要给元空间、线程栈和其他原生内存预留空间，所以这里额外留出约 500M，更符合实际运行需求。--cpus 1：限制可用 CPU，避免单个服务无限争抢资源。--restart=on-failure:5：容器异常退出时最多自动重启 5 次，适合应对短暂性故障。-v /home/myproject/logs:/app/logs：把日志目录挂载到宿主机，便于直接查看和留存日志文件。
Quartz 缺表导致启动失败，怎么定位和修复
如果镜像能构建成功、容器也拉起来了，但应用一启动就马上退出，先别急着怀疑 Dockerfile。对集成了 Quartz 的项目来说，数据库表结构不完整是很常见的一类原因。
先看日志里的直接报错
通过下面的命令查看容器实时日志：
docker logs -f myproject-app
示例报错如下：
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'sysJobServiceImpl': ... Caused by: org.quartz.impl.jdbcjobstore.LockException: Failure obtaining db row lock: Table 'db_name.QRTZ_LOCKS' doesn't exist
这类信息已经说明问题不在镜像构建阶段，而是在应用初始化 Quartz 时访问了数据库中的 QRTZ_LOCKS 表，但该表不存在。
为什么会报这个错
项目使用了 Quartz 定时任务框架，并且启用了 JDBC 持久化模式。只要是这种模式，数据库里就必须提前准备好一套以 QRTZ_ 开头的标准表结构。只要缺少其中关键表，应用在创建相关 Bean 或初始化调度器时就会直接失败。
导入脚本时可能遇到的第二层报错
很多人会先去找项目里的 sql/quartz.sql 脚本并直接导入，但这一步不一定一次成功，常见报错如下：
ERROR 1826 (HY000): Duplicate foreign key constraint name 'QRTZ_TRIGGERS_ibfk_1' ERROR 1824 (HY000): Failed to open the referenced table 'QRTZ_TRIGGERS'
这通常意味着两件事之一：
- 脚本里的建表顺序和外键依赖关系比较严格，中间任何一步失败都会连锁报错。
- 数据库中可能残留了之前执行失败后的元数据或部分表结构，导致再次导入时出现外键名冲突。
可落地的处理办法
更稳妥的做法是先关闭外键检查，清掉残留表，再按可执行顺序重建 Quartz 表。原文给出的处理思路如下：
-- 1. 清理环境 SET FOREIGN_KEY_CHECKS = 0; DROP TABLE IF EXISTS QRTZ_FIRED_TRIGGERS; DROP TABLE IF EXISTS QRTZ_PAUSED_TRIGGER_GRPS; DROP TABLE IF EXISTS QRTZ_SCHEDULER_STATE; DROP TABLE IF EXISTS QRTZ_LOCKS; DROP TABLE IF EXISTS QRTZ_SIMPLE_TRIGGERS; DROP TABLE IF EXISTS QRTZ_SIMPROP_TRIGGERS; DROP TABLE IF EXISTS QRTZ_CRON_TRIGGERS; DROP TABLE IF EXISTS QRTZ_BLOB_TRIGGERS; DROP TABLE IF EXISTS QRTZ_TRIGGERS; DROP TABLE IF EXISTS QRTZ_JOB_DETAILS; DROP TABLE IF EXISTS QRTZ_CALENDARS; -- 2. 建表语句（省略具体字段，请参考Quartz官方SQL） CREATE TABLE QRTZ_JOB_DETAILS (...) ENGINE=InnoDB; CREATE TABLE QRTZ_TRIGGERS (...) ENGINE=InnoDB; CREATE TABLE QRTZ_SIMPLE_TRIGGERS (...) ENGINE=InnoDB; -- ... 其他表 ... -- 3. 恢复检查 SET FOREIGN_KEY_CHECKS = 1;
这个思路的核心不是“强行绕过错误”，而是先让数据库回到一个干净、可控的状态，再重建 Quartz 依赖的标准表结构。对于已经出现外键冲突或残留脏数据的环境，这样做通常比反复直接执行原始脚本更有效。
修复后重启容器验证
表结构处理完成后，重启容器：
docker restart myproject-app
如果日志中出现 Started Application，说明这次启动已经通过，Quartz 初始化问题也随之解决。
部署后常用的排查与运维命令
容器跑起来后，后续运维最常用的通常就三类命令：看日志、进容器、拷文件。记住这几个高频操作，线上排查会快很多。
查看实时日志
docker logs -f myproject-app
适合观察启动过程、异常堆栈以及应用运行时输出。
进入容器内部排查
由于示例镜像基于 Alpine，进入容器时用的是 sh，不是某些系统里常见的 bash：
docker exec -it myproject-app sh
把容器里的文件复制到宿主机
docker cp myproject-app:/app/logs/sys-info.log /home/
当需要单独导出日志或其他运行文件时，这个命令很直接，也不依赖额外挂载。
这套部署流程最该记住的几点
把整个流程串起来看，Spring Boot 项目的 Docker 部署并不复杂，但线上是否稳定，往往取决于几个容易被忽视的细节：
- 打包前先核对生产配置，尤其是数据库、Redis 和上传目录，不要把开发环境配置直接带进容器。
- Dockerfile 里要把时区、JVM 参数和启动方式写清楚，避免启动慢、时间错乱或内存失控。
- 遇到 Quartz 相关报错时，优先检查数据库里是否已经存在完整的
QRTZ_表结构，而不是只盯着容器命令本身。 - MySQL 外键冲突场景下，
SET FOREIGN_KEY_CHECKS = 0配合清理残留表后重建，通常比重复导入原脚本更容易跑通。
如果你的目标是把 Spring Boot 服务稳定放到 Docker 中运行，这套顺序基本够用：先改配置，再打包，再用明确的 Dockerfile 构建镜像，最后通过日志定位数据库或框架初始化问题。真正决定部署成败的，通常不是命令有多复杂，而是这些前置条件是否处理到位。
