JeecgBoot 的 Docker 化部署是团队内部用得最多的一条路径尤其是需要把项目快速推到测试环境或者预发环境的时候容器化能省掉大量在我机器上没问题的扯皮时间。下面按实际操作的顺序把从本地构建到服务器上线的完整流程拆一遍。环境准备与版本确认动手之前先检查 Docker 和 docker-compose 的版本。JeecgBoot 官方镜像基于较新的基础镜像构建Docker 建议 20.10 以上docker-compose 建议 2.x 版本。可以用下面两条命令快速确认docker --version docker-compose --version如果版本偏低建议先升级。老版本的 docker-compose 在解析部分健康检查配置时会有兼容性问题这点在 JeecgBoot 的 MySQL 服务启动阶段尤其明显。项目内置的容器编排结构JeecgBoot 在源码根目录提供了完整的docker-compose.yml不需要自己从零写。打开这个文件能看到它编排了这几个核心服务MySQL 8.0业务主库初始化脚本会自动挂载到/docker-entrypoint-initdb.dRedis 7.x缓存与会话存储jeecg-boot-backendSpring Boot 后端服务镜像jeecg-boot-frontendVue3 前端构建后的 Nginx 镜像这几个服务之间的依赖关系在depends_on里已经声明清楚后端等 MySQL 和 Redis 就绪才会启动前端则相对独立。实际部署时这个顺序能避免大量数据库还没准备好后端就疯狂重试的情况。镜像构建与启动第一步准备环境变量文件JeecgBoot 把不同环境的配置拆到了独立的.env文件里。项目目录下通常能看到文件用途.env.development本地开发连本地或容器内的 MySQL/Redis.env.production生产环境数据库连接地址、密码强度都不同.env.dockerDocker 专属配置覆盖部分容器网络相关的变量关键区分点生产环境的数据库连接串通常指向独立的 RDS 实例或宿主机网络而不是 docker-compose 内部的服务名。修改时重点看DB_HOST、DB_PASSWORD、REDIS_HOST这几个变量确认它们指向的是正确的地址。第二步执行构建与启动在docker-compose.yml所在目录执行# 开发环境一键启动 docker-compose --env-file .env.development up -d --build # 生产环境 docker-compose --env-file .env.production up -d --build--build会在首次或 Dockerfile 变更时重新打包镜像。如果只是想重启服务去掉这个参数能快不少。构建完成后用docker-compose ps查看服务状态正常应该看到四个容器都是Up状态。常见问题排查容器起不来的时候先别急着删了重来按这个顺序定位效率最高。查看容器日志# 看后端服务日志通常问题最多 docker logs -f jeecg-boot-backend # MySQL 启动失败常见是端口占用或权限问题 docker logs -f jeecg-boot-mysql # 实时跟踪所有服务 docker-compose logs -f-f参数是持续跟踪适合在启动阶段观察报错信息的滚动输出。典型故障清单端口冲突MySQL 默认映射宿主机的 3306 端口如果本地已经跑了另一个 MySQL 实例docker-compose 会报bind: address already in use。解决办法修改docker-compose.yml里的端口映射比如改成3307:3306同时同步修改.env文件里的DB_PORT。内存不足导致启动失败JeecgBoot 后端在初始化阶段需要一定内存容器环境如果限制得太死会出现 OOMKilled。用docker stats观察内存占用或者在docker-compose.yml里给后端服务显式声明services: jeecg-boot-backend: deploy: resources: limits: memory: 2G reservations: memory: 512M数据库连接超时后端日志里出现大量Communications link failure通常是 MySQL 还没完全初始化后端就开始连接了。虽然depends_on能保证容器启动顺序但保证不了服务就绪。可以临时给后端加个启动延迟或者配置更健壮的重试机制。生产环境的前端部署与 Nginx 反向代理容器里的前端镜像已经内置了 Nginx但生产环境往往有独立的 Nginx 网关做统一入口这时候需要配置反向代理规则。核心配置片段假设你的域名是app.example.comNginx 配置里重点关注api前缀的转发server { listen 80; server_name app.example.com; location / { root /var/www/jeecg-boot; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://jeecg-boot-backend: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; } }关键点location /api/这里的proxy_pass末尾带斜杠和不带斜杠行为不同。上面示例中带斜杠会把/api/user/list转发成/user/list如果后端接口设计里已经包含了/api前缀就需要去掉这个斜杠或者调整proxy_pass的目标路径。这个细节搞错前端请求会全部 404。如果前端静态资源是单独部署到 CDN 或对象存储的把root指向对应目录即可Nginx 只负责反向代理 API 请求到后端容器。从本地到服务器的完整闭环整个流程走下来本地用docker-compose验证镜像和配置确认无误后把相同的环境变量和编排文件同步到服务器通过 CI/CD 流水线或手动执行完成部署。数据库初始化脚本、Redis 数据持久化目录、后端日志挂载这些在生产环境都要检查一遍 volume 映射是否正确避免容器重建后数据丢失。JeecgBoot 的 Docker 支持已经相当成熟真正需要留意的不是命令本身而是环境变量在不同场景下的正确切换以及 Nginx 反向代理时路径转发的细微差别。把这些边界情况处理好容器化部署就能稳定跑起来。