用 Docker Compose Watch 缩短本地开发反馈链

如果团队已经用 Docker Compose 管理本地开发环境，下一步最值得补上的往往是把“保存文件到看到结果”这段路径变短。Docker 官方文档里的 Compose Watch 提供了一个轻量方案：在 compose.yaml 中为服务声明 develop.watch 规则，然后用 docker compose up --watch 启动项目。之后，Compose 会监听指定路径，在文件变更时执行同步、重建或同步后重启。

保存源码后，Compose Watch 按规则同步、重建或重启服务。 来源：Codex image generation

适合解决什么问题

传统 bind mount 很直接，但在跨平台团队里容易遇到两个麻烦。第一是大型目录会带来额外 I/O 压力，尤其是 node_modules 这类小文件密集目录。第二是宿主机和容器的系统、架构可能不同，某些编译产物或原生依赖同步进去后反而造成环境偏差。Compose Watch 的价值在于把同步规则写得更细，哪些目录同步，哪些文件触发重建，哪些配置只需要重启，都能按服务拆开。

Docker 文档说明，watch 面向使用 build 从本地源码构建的服务，路径相对项目目录，目录会递归监听，.dockerignore 规则会参与过滤。也就是说，它更适合日常开发中的前端、后端、脚本服务，不适合只依赖远程预构建镜像的服务。

三种动作怎么选

sync 适合热更新框架。比如 Vite、Webpack、Turbopack 或 Flask 这类开发模式中，源码同步到容器后，框架自己接管刷新。官方示例里，./web 可以同步到容器内 /src/web，并把 node_modules/ 排除掉。

rebuild 适合依赖或构建输入变化。比如 package.json、requirements.txt、锁文件或需要重新编译的入口改变时，单纯同步不够，Compose 会用 BuildKit 构建新镜像并替换运行中的服务。

sync+restart 适合配置文件。比如 nginx.conf、数据库配置或服务启动时才读取的设置，文件同步后重启进程即可生效，没必要完整重建镜像。

落地时的两个检查点

第一个检查点是容器内权限。官方文档提醒，Watch 需要容器镜像里有 stat、mkdir、rmdir 等常见命令，并且当前 USER 能写入目标路径。常见做法是在 Dockerfile 里用 COPY --chown 把初始源码交给非特权用户，避免后续同步失败。

第二个检查点是规则粒度。不要把整个仓库都交给 sync，优先把源码目录、配置文件、依赖声明拆成不同规则。这样能减少无关变更，也能让团队成员一眼看出某类文件保存后会发生什么。

一个小团队可直接采用的模式

前端服务可以把 src/ 或 web/ 设成 sync，把 package.json 和锁文件设成 rebuild。反向代理服务可以把 nginx.conf 设成 sync+restart。后端服务则按语言选择，解释型源码优先同步，依赖文件优先重建。最后，把启动命令固定成 docker compose up --watch，需要分离日志时再使用 docker compose watch。

这套做法的重点是让容器开发保持可声明、可回归。环境仍由 Compose 管理，反馈链路则变得更接近本机开发体验。

来源链接

• Docker Docs: Use Compose Watch
• Docker Docs: Compose Develop Specification