用 Docker Compose 打造可复用的本地开发环境：5 个实战技巧

在日常开发中，最耗时的往往不是写代码，而是"把环境跑起来"。不同机器上 Node、MySQL、Redis 的版本不一致，新人入职第一天的"环境配置日"几乎是常态。Docker Compose 的价值在于：用一份声明式 YAML 把依赖服务固化下来，让 docker compose up -d 成为团队统一的启动入口。下面分享 5 个我在真实项目里反复验证过的技巧。

1. 用命名卷保存数据，而不是绑定挂载

初学者常直接写 ./data:/var/lib/mysql。一旦目录权限不对，MySQL 启动就会报权限错误；换台机器又容易把旧数据混进来。更好的做法是声明命名卷：

services:
  db:
    image: mysql:8.4
    volumes:
      - db_data:/var/lib/mysql
volumes:
  db_data:

命名卷由 Docker 统一管理，备份时用 docker run --rm -v db_data:/data alpine tar czf - /data 即可导出，既干净又不易误删。

2. 用 healthcheck + depends_on 控制启动顺序

depends_on 默认只保证容器"已启动"，并不代表服务"已就绪"。数据库还在初始化时，应用就可能连接失败。给依赖服务加健康检查，再用 condition: service_healthy，可以让应用在依赖真正可用后再启动：

services:
  db:
    healthcheck:
      test: ["CMD", "mysqladmin", "ping", "-h", "localhost"]
      interval: 5s
      retries: 10
  web:
    depends_on:
      db:
        condition: service_healthy

3. 用多阶段构建把生产镜像做小

开发镜像里带编译器、带源码没问题，但生产镜像应当尽量精简。多阶段构建把"构建"和"运行"分开，只把产物拷进最终镜像：

FROM node:22 AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

FROM nginx:alpine
COPY --from=build /app/dist /usr/share/nginx/html

这样最终镜像通常只有几十 MB，攻击面也更小。

4. 用 .env 管理可变参数，避免把密钥写进 YAML

把端口、数据库密码等易变项放进 .env，Compose 会自动注入：

mysql:
  image: ${MYSQL_IMAGE:-mysql:8.4}
  environment:
    MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD:?err}

:?err 的写法可以在变量缺失时直接报错，比事后再排查空密码友好得多。记得把 .env 加入 .gitignore，只提交 .env.example。

5. 复用 compose 文件：base + override

团队既要在本地跑全部服务，又希望 CI 里只跑测试。用多文件组合，把公共部分放 compose.yaml，本地覆盖放 compose.override.yaml，CI 用独立的 compose.ci.yaml：

docker compose -f compose.yaml -f compose.ci.yaml up -d

Compose 会自动合并同名服务，减少重复定义。

小结

Docker Compose 不是"更轻量的 Kubernetes"，而是把"开发环境"变成可版本化、可复现的一份资产。先把数据与顺序管理好，再逐步做镜像瘦身和配置外置，团队的"环境配置日"就能真正消失。