1. 引言在之前的章节中我们已经完成了 Docker 基础镜像构建、多阶段构建以及 Compose 编排等核心内容。从这一章开始我们将把视角从「部署」转向「本地开发」探讨如何用 Docker 打造一套高效、一致的本地开发工作流。很多团队在引入 Docker 后会遇到一个尴尬的局面部署环境已经容器化但开发环境还是老一套——本地装 JDK、装 MySQL、装 Redis靠 IDE 直接跑应用。这样做的后果是开发环境与生产环境不一致环境配置问题层出不穷新成员 onboarding 成本高。本章将围绕三个核心主题展开热更新通过绑定挂载 Spring DevTools / 前端 HMR让容器内的代码改动即时生效远程调试通过 JDWP 端口映射让 IDEA / VS Code 直接调试容器内的 Java 进程Testcontainers用 Docker 动态起 MySQL / Redis 跑集成测试让测试环境与生产环境保持一致。最后我们会把这些能力串成一个完整的本地开发循环改代码 → 热更新 → 单测 → 集成测试。前置依赖建议先完成第 03 章Docker 基础命令与镜像管理和第 07 章Compose 多容器编排本章会大量复用其中的概念。2. 为什么本地开发也要容器化在讨论具体方案之前先明确一个问题本地开发容器化的价值到底是什么2.1 环境一致性传统开发模式下每个开发者的机器环境各不相同有人用 macOS、有人用 Windows、有人用 LinuxJDK 版本可能是 8、11、17MySQL 可能是 5.7 也可能是 8.0。这些差异会导致「在我机器上能跑」的经典问题。容器化之后开发环境、测试环境、生产环境共享同一份镜像定义从根本上消除了环境漂移。2.2 依赖隔离一个开发者可能同时维护多个项目项目 A 需要 MySQL 5.7项目 B 需要 MySQL 8.0项目 C 需要 Redis 6。如果全部装在宿主机上版本冲突是迟早的事。用 Docker 起依赖服务每个项目有自己独立的容器实例互不干扰用完即焚。2.3 快速 onboarding新成员加入团队时不需要花半天时间阅读「环境搭建文档」也不需要手动安装各种依赖。只需要gitclonerepodockercompose up-d一条命令开发环境就绪。3. 热更新绑定挂载 开发工具热更新Hot Reload是本地开发体验的关键。没有热更新每次改代码都要重启容器等待时间会严重打断开发节奏。3.1 绑定挂载Bind Mount绑定挂载是 Docker 提供的一种数据卷类型它把宿主机上的目录直接映射到容器内的目录。与命名卷Named Volume不同绑定挂载实时同步宿主机与容器之间的文件变化。在docker-compose.yml中绑定挂载的写法如下services:app:image:openjdk:17-jdk-slimvolumes:-./backend:/appworking_dir:/app这里把宿主机上的./backend目录挂载到容器的/app目录。宿主机上任何文件改动容器内立即可见。注意绑定挂载会覆盖镜像中对应路径的内容。如果镜像构建时在/app下放了编译产物挂载后这些产物会被宿主机目录内容遮蔽。3.2 Spring Boot 后端热更新Spring DevToolsSpring Boot 提供了spring-boot-devtools依赖它内置了**自动重启Automatic Restart**机制当 classpath 中的文件发生变化时应用会自动重启。在pom.xml中添加依赖dependencygroupIdorg.springframework.boot/groupIdartifactIdspring-boot-devtools/artifactIdscoperuntime/scopeoptionaltrue/optional/dependency配合绑定挂载完整的开发流程如下宿主机上修改 Java 源码IDE 自动编译生成新的.class文件绑定挂载将.class文件同步到容器Spring DevTools 检测到 classpath 变化自动重启应用。这里有一个关键点IDE 必须开启「自动编译」。IDEA 中通过Build → Build Project快捷键CtrlF9手动触发或开启Build project automatically选项。3.3 前端热更新Vite HMR前端开发中Vite 的 HMRHot Module Replacement是目前体验最好的方案之一。它能在不刷新页面的情况下实时替换修改的模块。在docker-compose.yml中配置前端服务services:frontend:image:node:18-alpinevolumes:-./frontend:/appworking_dir:/appcommand:npm run devports:-5173:5173Vite 默认监听5173端口。为了让容器内的 Vite 能被宿主机访问需要配置server.host// vite.config.jsexportdefault{server:{host:true,port:5173,watch:{usePolling:true}}}usePolling: true是容器环境下的关键配置。在 Docker 中文件系统事件inotify的传递可能不可靠开启轮询模式可以确保文件变化被 Vite 正确感知。3.4 坑位热更新与卷缓存冲突这是热更新场景下最常见的坑。绑定挂载会遮蔽镜像中的目录内容如果镜像构建时已经安装了依赖如node_modules挂载后这些依赖会被宿主机目录遮蔽。解决方案有两种方案一匿名卷技巧services:frontend:image:node:18-alpinevolumes:-./frontend:/app-/app/node_modules第二行/app/node_modules是一个匿名卷它会把容器内原有的node_modules保留下来不被宿主机目录遮蔽。这样宿主机上的node_modules不会干扰容器内已安装的依赖。方案二分离依赖目录在宿主机上把node_modules放在项目目录之外或者使用 pnpm 的全局存储。这种方式更彻底但配置复杂度更高。对于 Java 项目类似的坑出现在target/目录。建议在.dockerignore中排除编译产物避免宿主机与容器的编译产物互相干扰。4. 远程调试JDWP 端口映射调试是开发者的刚需。容器化之后IDE 无法直接 attach 到容器内的 JVM 进程需要通过 JDWPJava Debug Wire Protocol协议建立连接。4.1 开启 JDWP在启动 Java 应用时通过 JVM 参数开启调试端口java-agentlib:jdwptransportdt_socket,servery,suspendn,address*:5005-jarapp.jar参数说明transportdt_socket使用 Socket 传输serveryJVM 作为调试服务器等待 IDE 连接suspendn启动时不挂起立即运行如果设为yJVM 会等待调试器连接后才启动address*:5005监听所有网卡的 5005 端口。4.2 Compose 配置在docker-compose.yml中映射调试端口services:app:image:openjdk:17-jdk-slimports:-5005:5005environment:JAVA_TOOL_OPTIONS:-agentlib:jdwptransportdt_socket,servery,suspendn,address*:5005使用JAVA_TOOL_OPTIONS环境变量的好处是不需要修改 Dockerfile 或启动命令JVM 启动时会自动读取该环境变量并应用。4.3 IDEA 连接打开Run → Edit Configurations点击选择Remote JVM Debug填写 Host 为localhostPort 为5005使用默认的Attach to remote JVM模式点击Debug按钮即可连接。4.4 VS Code 连接在.vscode/launch.json中配置{version:0.2.0,configurations:[{type:java,name:Attach to Docker JVM,request:attach,hostName:localhost,port:5005}]}4.5 坑位JDWP 端口暴露安全JDWP 协议没有任何认证机制任何能访问该端口的人都可以连接并控制 JVM甚至可以执行任意代码。因此不要在生产环境开启 JDWP不要将调试端口暴露到公网仅在本地开发时映射调试端口且建议绑定到127.0.0.1ports:-127.0.0.1:5005:5005这样只有本机可以访问调试端口局域网内其他机器无法连接。5. Testcontainers让测试环境与生产一致Testcontainers 是一个 Java 测试库它允许在测试运行时动态创建 Docker 容器作为依赖服务。这意味着测试环境与生产环境使用完全相同的数据库、缓存中间件彻底告别「测试用 H2生产用 MySQL」的尴尬。5.1 为什么需要 Testcontainers传统集成测试的痛点测试环境依赖本地安装的 MySQL / Redis版本与生产不一致CI 环境需要手动安装依赖服务配置复杂测试数据污染本地开发数据库。Testcontainers 的解决方案测试启动时自动拉取镜像、启动容器测试结束自动销毁容器不留残留每个测试类可以使用独立的容器实例互不干扰。5.2 添加依赖在pom.xml中添加dependencygroupIdorg.testcontainers/groupIdartifactIdjunit-jupiter/artifactIdversion1.19.7/versionscopetest/scope/dependencydependencygroupIdorg.testcontainers/groupIdartifactIdmysql/artifactIdversion1.19.7/versionscopetest/scope/dependency5.3 编写集成测试以 ValidX 项目的用户服务为例测试用户注册接口TestcontainersclassUserServiceIntegrationTest{ContainerstaticMySQLContainer?mysqlnewMySQLContainer(mysql:8.0).withDatabaseName(validx).withUsername(test).withPassword(test);ContainerstaticGenericContainer?redisnewGenericContainer(redis:7-alpine).withExposedPorts(6379);DynamicPropertySourcestaticvoidregisterProperties(DynamicPropertyRegistryregistry){registry.add(spring.datasource.url,mysql::getJdbcUrl);registry.add(spring.datasource.username,mysql::getUsername);registry.add(spring.datasource.password,mysql::getPassword);registry.add(spring.data.redis.host,redis::getHost);registry.add(spring.data.redis.port,()-redis.getMappedPort(6379));}TestvoidtestRegisterUser(){// 调用注册接口验证数据库写入}}关键点说明Testcontainers注解管理容器的生命周期Container注解标记的静态字段会在测试类加载时启动容器DynamicPropertySource将容器的动态端口注入 Spring 配置无需硬编码端口。5.4 复用容器实例如果多个测试类使用相同的容器配置可以提取公共父类publicabstractclassAbstractIntegrationTest{staticfinalMySQLContainer?MYSQL;static{MYSQLnewMySQLContainer(mysql:8.0).withDatabaseName(validx).withUsername(test).withPassword(test);MYSQL.start();}DynamicPropertySourcestaticvoidregisterProperties(DynamicPropertyRegistryregistry){registry.add(spring.datasource.url,MYSQL::getJdbcUrl);registry.add(spring.datasource.username,MYSQL::getUsername);registry.add(spring.datasource.password,MYSQL::getPassword);}}子类继承该父类即可复用同一个 MySQL 容器避免每个测试类都启动一个新容器显著缩短测试时间。5.5 坑位Testcontainers 的 Docker 依赖与 CI 适配Testcontainers 依赖本机的 Docker 环境。在本地开发时需要确保 Docker Desktop 正在运行。在 CI 环境中需要额外配置GitHub Actions 示例jobs:test:runs-on:ubuntu-latestservices:docker:image:docker:24options:--privilegedsteps:-uses:actions/checkoutv4-uses:actions/setup-javav4with:distribution:temurinjava-version:17-name:Run testsrun:mvn verifyJenkins 示例pipeline{agent{docker{imagemaven:3.9-eclipse-temurin-17}}stages{stage(Test){steps{shmvn verify}}}}在 Jenkins 中需要确保 Jenkins 节点上有可用的 Docker 环境并且 Jenkins 用户有权限访问 Docker socket。注意在 CI 中运行 Testcontainers 时需要设置TESTCONTAINERS_RYUK_DISABLEDtrue环境变量如果使用 Ryuk 资源回收机制或者确保 CI 环境支持 Ryuk 容器的运行。6. 完整本地开发循环把前面的能力串起来一个完整的本地开发循环如下有问题通过修改代码热更新生效功能验证远程调试运行单元测试运行集成测试 Testcontainers提交代码6.1 启动开发环境# 启动依赖服务MySQL、Redisdockercompose up-dmysql redis# 启动后端热更新模式dockercompose up-dbackend# 启动前端HMR 模式dockercompose up-dfrontend6.2 日常开发流程改代码在宿主机上编辑源码热更新后端通过 Spring DevTools 自动重启前端通过 Vite HMR 实时刷新单测mvn test运行单元测试不依赖外部服务集成测试mvn verify运行集成测试Testcontainers 自动拉起 MySQL / Redis调试遇到问题时通过 JDWP 端口连接 IDE 调试。6.3 一键脚本为了简化操作可以写一个 Makefile.PHONY: dev up down test itest debug dev: docker compose up -d mysql redis docker compose up -d backend frontend up: docker compose up -d down: docker compose down test: mvn test itest: mvn verify debug: docker compose logs -f backend7. 总结本章我们完成了 Docker 本地开发工作流的完整搭建能力技术方案关键配置热更新绑定挂载 Spring DevTools / Vite HMRvolumesusePolling远程调试JDWP 端口映射JAVA_TOOL_OPTIONS 端口映射集成测试TestcontainersTestcontainersDynamicPropertySource三个核心坑位需要牢记热更新与卷缓存冲突绑定挂载会遮蔽镜像目录用匿名卷或分离依赖目录解决JDWP 端口暴露安全调试端口无认证仅绑定127.0.0.1生产环境禁用Testcontainers 的 Docker 依赖本地需 Docker DesktopCI 需额外配置 Docker 环境。Testcontainers 部分可以直接复用到 ValidX 项目的测试改造中让集成测试与生产环境保持一致从根源上消除「测试通过、上线失败」的问题。