开发期的热更新
compose watch 监视源码变化，并按规则同步进容器或重新构建：可以用 docker compose watch 单独运行，也可以在启动命令上加 --watch。规则写在服务的 develop.watch 段里，每个路径可以指定动作是同步还是重建。它面向开发阶段，同步只对支持热加载的运行时有效；后端进程不会因为文件变化自动重启，仍需配套的重启工具。
基本信息
| 用法 | docker compose watch [服务] 或 docker compose up --watch |
|---|---|
| 配置位置 | services.<服务>.develop.watch |
| 可用动作 | sync / rebuild / sync+restart |
| 定位 | 开发期替代反复手工重建 |
典型使用场景
- 前端开发：源码同步进容器，配合开发服务器热加载
- 后端联调：同步代码后由重启类工具重载进程
- 依赖变更：监视依赖清单，变化时自动重建镜像
- 多服务协同：以某一服务为主开发，其他服务保持不动
- 减少手工操作：把常用动作写进规则，团队内共享一致行为
规则配置
规则配置
services:
web:
build: .
develop:
watch:
- action: sync # 源码变化直接同步进容器
path: ./src
target: /app/src
- action: rebuild # 依赖变化时重新构建
path: package.json
# 启动监听
docker compose watch web动作与适用场景
| 动作 | 行为 | 适用条件 |
|---|---|---|
| sync | 把文件同步进容器现有路径 | 运行时支持热加载 |
| rebuild | 重新构建镜像并重建容器 | 依赖清单或构建配置变化 |
| sync+restart | 同步后重启容器主进程 | 改动需要重启才能加载 |
| 不配置规则 | 对构建上下文变化执行重建 | 先跑通再细化规则的场景 |
watch 属于较新的 Compose 能力，环境里的版本过旧时该子命令不可用，需要先升级。
把监听范围限定在源码目录：监视大目录会占用资源并触发频繁同步，构建产物与依赖目录应排除在外。
验证规则是否生效的简单办法：改一个源文件，观察同步日志有没有出现对应路径，再进容器确认目标位置的内容是否更新；两处都变才算规则写对。