简介这份资源是面向高校计算机专业学生与Java开发学习者的「基于Docker的大学生兼职平台」完整项目包适合作为毕业设计、课程设计或全栈练手参考。项目以Java为核心后端采用Spring Boot与MyBatis实现数据持久化前端结合现代Web技术完成响应式页面并借助Docker容器化实现快速部署与稳定运行同时涉及Redis缓存、HTTPS传输与OAuth2.0认证等安全设计。压缩包共535个文件约2.99MB其中188个java源文件构成后端主体99个js与48个html、24个css支撑前端交互另有2个sql数据库脚本、2个doc文档及yml配置等覆盖源码、数据库、开题报告与任务书。目前已有64人学习下载。读者可据此快速搭建测试环境理解容器化部署流程并参考文档中的需求分析与设计思路完成二次开发。1. 从一份「大学生兼职平台」压缩包说起Docker 到底解决了谁的痛点拿到「基于 Docker 的大学生兼职平台的设计与实现.zip」这个标题很多人第一反应是去翻源码但我更想先问一句为什么一个校园兼职平台非要套上 Docker答案藏在部署环节。传统做法是本地装 JDK、MySQL、Redis、Nginx版本一冲突就重装系统换台机器又得重来一遍。Docker 把运行环境连同应用一起打包成镜像docker compose up一条命令就能把后端、数据库、缓存全部拉起来这对需要频繁演示、答辩、迁移的毕设项目来说省下的不是几分钟而是整晚的排错时间。这篇文章面向正在做「设计与实现」类项目的学生和刚入行的后端把镜像分层、Compose 编排、数据持久化、网络互通这些点讲透让你拿到压缩包后能真正跑起来而不是对着报错发呆。2. 拆解平台架构Spring Boot MySQL Redis 为什么适合用 Docker 编排2.1 兼职平台的典型模块与容器划分一个能跑通业务的大学生兼职平台核心模块通常包括用户认证学生 / 商家双角色、兼职信息发布与检索、简历投递、订单状态流转、消息通知。对应到后端就是 Spring Boot 提供 REST 接口MySQL 存用户和兼职数据Redis 扛会话和热点列表缓存Nginx 做静态资源和反向代理。如果按传统方式部署这四样东西要分别安装、分别配置任何一处版本不匹配都会导致启动失败。用 Docker 的思路是把每个关注点拆成一个独立容器app容器跑 Spring Boot 打出的 jarmysql容器跑数据库redis容器跑缓存nginx容器做入口。容器之间通过自定义 bridge 网络用服务名互相访问比如 Spring Boot 的配置文件里写jdbc:mysql://mysql:3306/job_platform而不是localhost。这种拆分的好处是数据库崩了不影响应用镜像重建缓存要换版本只动一个 service 定义整个平台的可复现性直接拉满。常见做法是先用docker-compose.yml把四个服务串起来本地开发时只暴露必要端口生产环境再把 Nginx 的 80/443 放出去。下面是一个最小可用的编排骨架你可以直接对照自己的项目改。# docker-compose.yml version: 3.8 services: mysql: image: mysql:8.0 environment: MYSQL_ROOT_PASSWORD: root123 MYSQL_DATABASE: job_platform volumes: - mysql_data:/var/lib/mysql # 数据持久化容器删了数据还在 - ./sql/init.sql:/docker-entrypoint-initdb.d/init.sql # 首次启动自动建表 networks: - job-net redis: image: redis:7-alpine command: redis-server --appendonly yes # 开启 AOF 持久化 volumes: - redis_data:/data networks: - job-net app: build: ./backend # 指向 Spring Boot 项目根目录内含 Dockerfile depends_on: - mysql - redis environment: SPRING_DATASOURCE_URL: jdbc:mysql://mysql:3306/job_platform?useSSLfalse SPRING_REDIS_HOST: redis networks: - job-net nginx: image: nginx:alpine ports: - 80:80 volumes: - ./frontend/dist:/usr/share/nginx/html # 前端打包产物 - ./nginx.conf:/etc/nginx/conf.d/default.conf depends_on: - app networks: - job-net volumes: mysql_data: redis_data: networks: job-net: driver: bridge这段编排里depends_on只保证启动顺序不保证 MySQL 已经初始化完成所以 Spring Boot 侧要配重试或健康检查后面避坑章节会细说。volumes把数据库和缓存的数据落到命名卷避免docker compose down之后数据全丢。networks让四个容器在同一个 bridge 网络里直接用服务名当主机名这是 Docker 编排最舒服的地方。2.2 镜像分层与构建缓存为什么你的 jar 包要单独 COPY写 Dockerfile 时很多人习惯COPY . .一把梭结果每次改一行代码整个镜像从头构建依赖下载重来一遍。Docker 镜像是分层的每条指令生成一层只要层的内容没变就能命中缓存。正确做法是把「变化频率低」的操作放前面「变化频率高」的放后面。# backend/Dockerfile FROM eclipse-temurin:17-jre WORKDIR /app # 先只拷贝依赖描述文件利用缓存下载依赖 COPY pom.xml . RUN mvn dependency:go-offline -B # 再拷贝源码并打包 COPY src ./src RUN mvn package -DskipTests # 只把最终 jar 拷进运行层 RUN cp target/*.jar app.jar EXPOSE 8080 ENTRYPOINT [java, -jar, app.jar]这里的关键是pom.xml和src分两次 COPY。只要pom.xml没动mvn dependency:go-offline这一层就一直命中缓存改业务代码时构建时间能从几分钟降到十几秒。参数上-B是批处理模式避免交互式输出干扰日志-DskipTests在镜像构建阶段跳过测试测试应该放在 CI 里跑不要拖慢镜像构建。如果你用的是 Gradle思路一样先 COPYbuild.gradle和settings.gradle再 COPY 源码。注意eclipse-temurin:17-jre是运行层不要用-jdk镜像跑生产体积大且没必要。构建阶段可以用多阶段构建把 Maven 和 JDK 留在 builder 阶段最终镜像只保留 JRE 和 jar。3. 从零跑通把压缩包变成能访问的本地服务3.1 环境准备与 Docker 安装的版本选择拿到压缩包后第一步不是急着docker compose up而是确认本机 Docker 环境。Windows 用户装 Docker Desktop安装时如果提示virtualization support not detected要去 BIOS 里开虚拟化Intel VT-x 或 AMD-V这是血泪经验里出现频率最高的翻车点。装完后在终端执行docker version和docker compose version两个都能输出版本号才算就绪。Linux 用户用apt install docker.io docker-compose-plugin或官方脚本安装装完把当前用户加进 docker 组否则每条命令都要 sudo。# 验证 Docker 与 Compose 是否可用 docker version docker compose version # 查看当前镜像和容器确认没有端口冲突 docker ps -a docker images如果docker compose version报错说明装的是老版docker-compose带横杠命令要改成docker-compose。新版插件式命令是docker compose空格两者配置文件兼容但脚本里别混用。国内拉镜像慢是常态可以在 Docker Desktop 设置里配镜像加速地址或者用docker pull时指定可访问的仓库这一步不解决后面构建会卡在下载依赖上。3.2 数据库初始化与首次启动顺序MySQL 容器首次启动时会执行/docker-entrypoint-initdb.d/下的 SQL 文件这是建表和插入初始数据的时机。把项目的建表脚本放到sql/init.sql编排里挂载进去容器第一次启动就会自动执行。但要注意这个目录只在数据目录为空时执行如果你已经启动过一次改了 init.sql 也不会重新跑必须docker compose down -v删掉卷再起。# 首次启动后台运行 docker compose up -d # 查看各容器状态mysql 显示 healthy 才算真正就绪 docker compose ps # 跟踪 app 日志确认 Spring Boot 连上了数据库 docker compose logs -f app启动顺序上depends_on只保证 mysql 容器先启动不保证 MySQL 服务已经能接受连接。Spring Boot 启动太快时会出现Communications link failure。解决办法有两个一是在 Spring Boot 里配 HikariCP 的initializationFailTimeout和重试二是在 compose 里给 mysql 加 healthcheck让 app 依赖condition: service_healthy。mysql: image: mysql:8.0 healthcheck: test: [CMD, mysqladmin, ping, -h, localhost, -uroot, -proot123] interval: 5s timeout: 3s retries: 10 app: depends_on: mysql: condition: service_healthy redis: condition: service_startedhealthcheck 的interval是检查间隔retries是失败重试次数两者相乘大致就是最长等待时间。MySQL 8 首次初始化可能要 20 到 30 秒retries: 10配合interval: 5s基本够用。这一步配好能省掉大量「为什么 app 一直重启」的排查时间。3.3 前后端联调与端口映射的常见配置前端如果是 Vue 或 React 打包成静态文件交给 Nginx 容器托管最省事。Nginx 配置里把/api反向代理到app:8080前端代码里请求写相对路径/api/xxx这样本地和线上都不用改 baseURL。# nginx.conf server { listen 80; location / { root /usr/share/nginx/html; try_files $uri $uri/ /index.html; # 支持前端路由刷新 } location /api/ { proxy_pass http://app:8080/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }try_files这行是单页应用刷新 404 的解药没有它用户在/job/123页面按 F5 就会看到 Nginx 404。proxy_pass末尾的斜杠决定路径是否截断http://app:8080/会把/api/job转成/job而http://app:8080会保留/api/job这个细节对不上接口就全 404。端口映射上本地开发只暴露 Nginx 的 80MySQL 和 Redis 不映射到宿主机减少端口冲突和安全面。需要连数据库调试时临时加ports: 3306:3306调完删掉。4. 避坑与排查Docker 部署兼职平台最容易翻车的五件事4.1 现象app 容器反复重启日志报数据库连接失败原因通常是 MySQL 还没初始化完Spring Boot 就急着连。depends_on默认只等容器启动不等服务就绪。解决给 mysql 加 healthcheckapp 的 depends_on 改成condition: service_healthy同时在 Spring Boot 的 datasource 配置里加连接重试参数双保险。4.2 现象改了代码重新构建镜像里还是旧 jar原因是 Dockerfile 里COPY . .之后没有重新打包或者构建时命中了旧缓存。解决确认 Dockerfile 里mvn package在 COPY 源码之后执行构建时加--no-cache强制不用缓存排查一次更稳妥的是用多阶段构建builder 阶段打包运行阶段只 COPY jar逻辑清晰不易错。4.3 现象容器之间 ping 不通app 连不上 mysql原因是服务不在同一个网络或者用了localhost而不是服务名。解决确认 compose 里所有服务都声明了同一个networks连接字符串里主机名必须写服务名mysql不能写127.0.0.1因为容器里的 localhost 指向容器自己。用docker compose exec app ping mysql验证网络连通性。4.4 现象docker compose down之后数据全没了原因是数据没有持久化MySQL 的数据写在容器可写层容器一删就丢。解决给 mysql 和 redis 配命名卷volumes: - mysql_data:/var/lib/mysql。注意docker compose down默认不删卷但down -v会删生产环境慎用-v。4.5 现象前端刷新页面 404接口请求跨域原因是 Nginx 没配try_files以及前端直接请求了app:8080而不是走 Nginx 代理。解决Nginx 里加try_files $uri $uri/ /index.html前端统一用/api相对路径由 Nginx 反向代理跨域问题自然消失不需要在后端配 CORS。5. 进阶技巧用多阶段构建和健康检查把镜像压到最小把平台跑起来只是第一步真正让这个「设计与实现」拿得出手的是镜像体积和启动可靠性。我一般会用多阶段构建把最终镜像从 600MB 压到 200MB 以内再配合健康检查让编排自己处理依赖顺序。# 多阶段构建builder 阶段负责编译 FROM maven:3.9-eclipse-temurin-17 AS builder WORKDIR /build COPY pom.xml . RUN mvn dependency:go-offline -B COPY src ./src RUN mvn package -DskipTests # 运行阶段只保留 JRE 和 jar FROM eclipse-temurin:17-jre WORKDIR /app COPY --frombuilder /build/target/*.jar app.jar EXPOSE 8080 ENTRYPOINT [java, -Xms256m, -Xmx512m, -jar, app.jar]COPY --frombuilder只把 jar 从构建阶段搬过来Maven 仓库、源码、JDK 全部留在 builder 层最终镜像干净很多。-Xms256m -Xmx512m限制堆内存避免容器被 OOM Kill具体数值按你服务器内存调整一般不超过容器内存限制的 75%。验证镜像是否达标可以用docker images看体积用docker history看每层大小找出异常大的层。启动可靠性上给 app 也加 healthcheck指向 Spring Boot Actuator 的/actuator/health这样 Nginx 可以依赖 app 健康后再启动。检查项命令合格标准镜像体积docker imagesapp 镜像小于 250MB层大小docker history image无异常大层服务健康docker compose ps全部 healthy数据持久化docker volume ls存在 mysql_data、redis_data网络连通docker compose exec app ping mysql能通这套流程我踩过最深的坑是早期图省事把 MySQL 密码写死在 Dockerfile 里结果镜像一推仓库密码就泄露。后来养成习惯所有敏感配置走环境变量或.env文件.env加进.gitignorecompose 里用${MYSQL_PASSWORD}引用。还有一次是docker compose down -v手滑删了演示数据答辩前夜重新造数据到凌晨从那以后演示环境的数据卷我必做定期备份。希望帮到你。本文还有配套的精品资源点击获取
Docker部署大学生兼职平台：Spring Boot+MySQL+Redis容器化实战
简介这份资源是面向高校计算机专业学生与Java开发学习者的「基于Docker的大学生兼职平台」完整项目包适合作为毕业设计、课程设计或全栈练手参考。项目以Java为核心后端采用Spring Boot与MyBatis实现数据持久化前端结合现代Web技术完成响应式页面并借助Docker容器化实现快速部署与稳定运行同时涉及Redis缓存、HTTPS传输与OAuth2.0认证等安全设计。压缩包共535个文件约2.99MB其中188个java源文件构成后端主体99个js与48个html、24个css支撑前端交互另有2个sql数据库脚本、2个doc文档及yml配置等覆盖源码、数据库、开题报告与任务书。目前已有64人学习下载。读者可据此快速搭建测试环境理解容器化部署流程并参考文档中的需求分析与设计思路完成二次开发。1. 从一份「大学生兼职平台」压缩包说起Docker 到底解决了谁的痛点拿到「基于 Docker 的大学生兼职平台的设计与实现.zip」这个标题很多人第一反应是去翻源码但我更想先问一句为什么一个校园兼职平台非要套上 Docker答案藏在部署环节。传统做法是本地装 JDK、MySQL、Redis、Nginx版本一冲突就重装系统换台机器又得重来一遍。Docker 把运行环境连同应用一起打包成镜像docker compose up一条命令就能把后端、数据库、缓存全部拉起来这对需要频繁演示、答辩、迁移的毕设项目来说省下的不是几分钟而是整晚的排错时间。这篇文章面向正在做「设计与实现」类项目的学生和刚入行的后端把镜像分层、Compose 编排、数据持久化、网络互通这些点讲透让你拿到压缩包后能真正跑起来而不是对着报错发呆。2. 拆解平台架构Spring Boot MySQL Redis 为什么适合用 Docker 编排2.1 兼职平台的典型模块与容器划分一个能跑通业务的大学生兼职平台核心模块通常包括用户认证学生 / 商家双角色、兼职信息发布与检索、简历投递、订单状态流转、消息通知。对应到后端就是 Spring Boot 提供 REST 接口MySQL 存用户和兼职数据Redis 扛会话和热点列表缓存Nginx 做静态资源和反向代理。如果按传统方式部署这四样东西要分别安装、分别配置任何一处版本不匹配都会导致启动失败。用 Docker 的思路是把每个关注点拆成一个独立容器app容器跑 Spring Boot 打出的 jarmysql容器跑数据库redis容器跑缓存nginx容器做入口。容器之间通过自定义 bridge 网络用服务名互相访问比如 Spring Boot 的配置文件里写jdbc:mysql://mysql:3306/job_platform而不是localhost。这种拆分的好处是数据库崩了不影响应用镜像重建缓存要换版本只动一个 service 定义整个平台的可复现性直接拉满。常见做法是先用docker-compose.yml把四个服务串起来本地开发时只暴露必要端口生产环境再把 Nginx 的 80/443 放出去。下面是一个最小可用的编排骨架你可以直接对照自己的项目改。# docker-compose.yml version: 3.8 services: mysql: image: mysql:8.0 environment: MYSQL_ROOT_PASSWORD: root123 MYSQL_DATABASE: job_platform volumes: - mysql_data:/var/lib/mysql # 数据持久化容器删了数据还在 - ./sql/init.sql:/docker-entrypoint-initdb.d/init.sql # 首次启动自动建表 networks: - job-net redis: image: redis:7-alpine command: redis-server --appendonly yes # 开启 AOF 持久化 volumes: - redis_data:/data networks: - job-net app: build: ./backend # 指向 Spring Boot 项目根目录内含 Dockerfile depends_on: - mysql - redis environment: SPRING_DATASOURCE_URL: jdbc:mysql://mysql:3306/job_platform?useSSLfalse SPRING_REDIS_HOST: redis networks: - job-net nginx: image: nginx:alpine ports: - 80:80 volumes: - ./frontend/dist:/usr/share/nginx/html # 前端打包产物 - ./nginx.conf:/etc/nginx/conf.d/default.conf depends_on: - app networks: - job-net volumes: mysql_data: redis_data: networks: job-net: driver: bridge这段编排里depends_on只保证启动顺序不保证 MySQL 已经初始化完成所以 Spring Boot 侧要配重试或健康检查后面避坑章节会细说。volumes把数据库和缓存的数据落到命名卷避免docker compose down之后数据全丢。networks让四个容器在同一个 bridge 网络里直接用服务名当主机名这是 Docker 编排最舒服的地方。2.2 镜像分层与构建缓存为什么你的 jar 包要单独 COPY写 Dockerfile 时很多人习惯COPY . .一把梭结果每次改一行代码整个镜像从头构建依赖下载重来一遍。Docker 镜像是分层的每条指令生成一层只要层的内容没变就能命中缓存。正确做法是把「变化频率低」的操作放前面「变化频率高」的放后面。# backend/Dockerfile FROM eclipse-temurin:17-jre WORKDIR /app # 先只拷贝依赖描述文件利用缓存下载依赖 COPY pom.xml . RUN mvn dependency:go-offline -B # 再拷贝源码并打包 COPY src ./src RUN mvn package -DskipTests # 只把最终 jar 拷进运行层 RUN cp target/*.jar app.jar EXPOSE 8080 ENTRYPOINT [java, -jar, app.jar]这里的关键是pom.xml和src分两次 COPY。只要pom.xml没动mvn dependency:go-offline这一层就一直命中缓存改业务代码时构建时间能从几分钟降到十几秒。参数上-B是批处理模式避免交互式输出干扰日志-DskipTests在镜像构建阶段跳过测试测试应该放在 CI 里跑不要拖慢镜像构建。如果你用的是 Gradle思路一样先 COPYbuild.gradle和settings.gradle再 COPY 源码。注意eclipse-temurin:17-jre是运行层不要用-jdk镜像跑生产体积大且没必要。构建阶段可以用多阶段构建把 Maven 和 JDK 留在 builder 阶段最终镜像只保留 JRE 和 jar。3. 从零跑通把压缩包变成能访问的本地服务3.1 环境准备与 Docker 安装的版本选择拿到压缩包后第一步不是急着docker compose up而是确认本机 Docker 环境。Windows 用户装 Docker Desktop安装时如果提示virtualization support not detected要去 BIOS 里开虚拟化Intel VT-x 或 AMD-V这是血泪经验里出现频率最高的翻车点。装完后在终端执行docker version和docker compose version两个都能输出版本号才算就绪。Linux 用户用apt install docker.io docker-compose-plugin或官方脚本安装装完把当前用户加进 docker 组否则每条命令都要 sudo。# 验证 Docker 与 Compose 是否可用 docker version docker compose version # 查看当前镜像和容器确认没有端口冲突 docker ps -a docker images如果docker compose version报错说明装的是老版docker-compose带横杠命令要改成docker-compose。新版插件式命令是docker compose空格两者配置文件兼容但脚本里别混用。国内拉镜像慢是常态可以在 Docker Desktop 设置里配镜像加速地址或者用docker pull时指定可访问的仓库这一步不解决后面构建会卡在下载依赖上。3.2 数据库初始化与首次启动顺序MySQL 容器首次启动时会执行/docker-entrypoint-initdb.d/下的 SQL 文件这是建表和插入初始数据的时机。把项目的建表脚本放到sql/init.sql编排里挂载进去容器第一次启动就会自动执行。但要注意这个目录只在数据目录为空时执行如果你已经启动过一次改了 init.sql 也不会重新跑必须docker compose down -v删掉卷再起。# 首次启动后台运行 docker compose up -d # 查看各容器状态mysql 显示 healthy 才算真正就绪 docker compose ps # 跟踪 app 日志确认 Spring Boot 连上了数据库 docker compose logs -f app启动顺序上depends_on只保证 mysql 容器先启动不保证 MySQL 服务已经能接受连接。Spring Boot 启动太快时会出现Communications link failure。解决办法有两个一是在 Spring Boot 里配 HikariCP 的initializationFailTimeout和重试二是在 compose 里给 mysql 加 healthcheck让 app 依赖condition: service_healthy。mysql: image: mysql:8.0 healthcheck: test: [CMD, mysqladmin, ping, -h, localhost, -uroot, -proot123] interval: 5s timeout: 3s retries: 10 app: depends_on: mysql: condition: service_healthy redis: condition: service_startedhealthcheck 的interval是检查间隔retries是失败重试次数两者相乘大致就是最长等待时间。MySQL 8 首次初始化可能要 20 到 30 秒retries: 10配合interval: 5s基本够用。这一步配好能省掉大量「为什么 app 一直重启」的排查时间。3.3 前后端联调与端口映射的常见配置前端如果是 Vue 或 React 打包成静态文件交给 Nginx 容器托管最省事。Nginx 配置里把/api反向代理到app:8080前端代码里请求写相对路径/api/xxx这样本地和线上都不用改 baseURL。# nginx.conf server { listen 80; location / { root /usr/share/nginx/html; try_files $uri $uri/ /index.html; # 支持前端路由刷新 } location /api/ { proxy_pass http://app:8080/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }try_files这行是单页应用刷新 404 的解药没有它用户在/job/123页面按 F5 就会看到 Nginx 404。proxy_pass末尾的斜杠决定路径是否截断http://app:8080/会把/api/job转成/job而http://app:8080会保留/api/job这个细节对不上接口就全 404。端口映射上本地开发只暴露 Nginx 的 80MySQL 和 Redis 不映射到宿主机减少端口冲突和安全面。需要连数据库调试时临时加ports: 3306:3306调完删掉。4. 避坑与排查Docker 部署兼职平台最容易翻车的五件事4.1 现象app 容器反复重启日志报数据库连接失败原因通常是 MySQL 还没初始化完Spring Boot 就急着连。depends_on默认只等容器启动不等服务就绪。解决给 mysql 加 healthcheckapp 的 depends_on 改成condition: service_healthy同时在 Spring Boot 的 datasource 配置里加连接重试参数双保险。4.2 现象改了代码重新构建镜像里还是旧 jar原因是 Dockerfile 里COPY . .之后没有重新打包或者构建时命中了旧缓存。解决确认 Dockerfile 里mvn package在 COPY 源码之后执行构建时加--no-cache强制不用缓存排查一次更稳妥的是用多阶段构建builder 阶段打包运行阶段只 COPY jar逻辑清晰不易错。4.3 现象容器之间 ping 不通app 连不上 mysql原因是服务不在同一个网络或者用了localhost而不是服务名。解决确认 compose 里所有服务都声明了同一个networks连接字符串里主机名必须写服务名mysql不能写127.0.0.1因为容器里的 localhost 指向容器自己。用docker compose exec app ping mysql验证网络连通性。4.4 现象docker compose down之后数据全没了原因是数据没有持久化MySQL 的数据写在容器可写层容器一删就丢。解决给 mysql 和 redis 配命名卷volumes: - mysql_data:/var/lib/mysql。注意docker compose down默认不删卷但down -v会删生产环境慎用-v。4.5 现象前端刷新页面 404接口请求跨域原因是 Nginx 没配try_files以及前端直接请求了app:8080而不是走 Nginx 代理。解决Nginx 里加try_files $uri $uri/ /index.html前端统一用/api相对路径由 Nginx 反向代理跨域问题自然消失不需要在后端配 CORS。5. 进阶技巧用多阶段构建和健康检查把镜像压到最小把平台跑起来只是第一步真正让这个「设计与实现」拿得出手的是镜像体积和启动可靠性。我一般会用多阶段构建把最终镜像从 600MB 压到 200MB 以内再配合健康检查让编排自己处理依赖顺序。# 多阶段构建builder 阶段负责编译 FROM maven:3.9-eclipse-temurin-17 AS builder WORKDIR /build COPY pom.xml . RUN mvn dependency:go-offline -B COPY src ./src RUN mvn package -DskipTests # 运行阶段只保留 JRE 和 jar FROM eclipse-temurin:17-jre WORKDIR /app COPY --frombuilder /build/target/*.jar app.jar EXPOSE 8080 ENTRYPOINT [java, -Xms256m, -Xmx512m, -jar, app.jar]COPY --frombuilder只把 jar 从构建阶段搬过来Maven 仓库、源码、JDK 全部留在 builder 层最终镜像干净很多。-Xms256m -Xmx512m限制堆内存避免容器被 OOM Kill具体数值按你服务器内存调整一般不超过容器内存限制的 75%。验证镜像是否达标可以用docker images看体积用docker history看每层大小找出异常大的层。启动可靠性上给 app 也加 healthcheck指向 Spring Boot Actuator 的/actuator/health这样 Nginx 可以依赖 app 健康后再启动。检查项命令合格标准镜像体积docker imagesapp 镜像小于 250MB层大小docker history image无异常大层服务健康docker compose ps全部 healthy数据持久化docker volume ls存在 mysql_data、redis_data网络连通docker compose exec app ping mysql能通这套流程我踩过最深的坑是早期图省事把 MySQL 密码写死在 Dockerfile 里结果镜像一推仓库密码就泄露。后来养成习惯所有敏感配置走环境变量或.env文件.env加进.gitignorecompose 里用${MYSQL_PASSWORD}引用。还有一次是docker compose down -v手滑删了演示数据答辩前夜重新造数据到凌晨从那以后演示环境的数据卷我必做定期备份。希望帮到你。本文还有配套的精品资源点击获取
