Docker Compose热更新与重建需区分开发与部署场景：开发用volume挂载+nodemon实现秒级热重载，或watch功能精细控制sync/rebuild；部署则用--build配合deploy滚动更新策略（parallelism/delay/order）保障零停机。
Docker Compose 实现热更新与重新构建，关键在于区分两种场景：开发阶段的“零感知代码变更”和部署阶段的“镜像级更新”。前者追求不重启、秒生效；后者强调可控替换、服务不中断。选错方式会导致效率低下或服务抖动。
开发环境：用 volume 挂载 + 开发服务器实现热重载
这是最轻量、最常用的热更新方式，适合日常编码调试。
- 在 docker-compose.yml 中通过
volumes将本地代码目录挂载进容器，例如：- ./src:/app/src和- ./package.json:/app/package.json - 容器内运行支持热重载的工具，比如
nodemon（Node.js）、webpack-dev-server（前端）或ts-node-dev - 修改本地文件后，挂载机制自动同步到容器，开发服务器监听到变化即重启进程或触发 HMR
- 注意避开
node_modules和.git等目录，避免干扰或权限问题
开发环境进阶：Compose 3.8+ 的 watch 功能替代手动挂载
当需要更精细控制（比如区分静态资源同步、依赖重建、配置重启），推荐启用 develop.watch。
- 配置示例中定义三种动作：
sync（如 HTML/JS 文件变更 → 直接复制进容器）rebuild（如package.json变更 → 增量构建新镜像）sync+restart（如.env或配置文件变更 → 同步后重启服务） - 启动命令不再是
docker-compose up，而是：docker compose watch（注意是compose，非compose） - 该功能底层调用
pkg/compose/watch.go中的同步逻辑，比传统挂载更稳定，且避免了某些 Linux 文件系统 inotify 事件丢失问题
部署更新：用 --build + 更新策略实现平滑发布
生产或测试环境不允许挂载源码，必须靠镜像更新。核心是“构建新镜像 + 替换旧容器”，同时保障可用性。
- 执行
docker compose up -d --build：强制重建镜像并后台更新服务 - 若需滚动更新（多副本不中断），需在
deploy中配置：replicas: 3（维持 3 个实例）update_config:
parallelism: 1（每次只更新 1 个）
delay: 10s（批次间隔）
order: start-first（先启新、再停旧） - 搭配
healthcheck更可靠：确保新容器真正就绪后再下线旧实例
特殊情况：热修复二进制文件（跳过完整构建）
当只修一个 bug、时间紧迫，又不想走完整 CI 流程时，可直接覆盖容器内可执行文件。
- 准备修复后的二进制（如
server），写一个极简 Dockerfile：FROM 原镜像COPY server /usr/local/bin/serverRUN chmod +x /usr/local/bin/server - 构建新镜像并推送，然后用
docker compose up -d拉取并替换服务 - 此法绕过源码编译，速度快，但需确保新文件兼容原镜像环境（glibc 版本、依赖库等）
