depends_on 就绪条件

• depends_on: 单独使用仅等待容器启动——服务很可能尚未真正就绪
• 需配合健康检查（healthcheck）及条件判断，才能实现真正的就绪等待：

depends_on:
  db:
    condition: service_healthy

• 若目标服务未定义 healthcheck，则 service_healthy 条件将失败

健康检查的 start_period

healthcheck:
  test: ["CMD", "pg_isready"]
  start_period: 30s

• start_period：初始宽限期——在此期间内的健康检查失败不计入失败次数
• 启动较慢的服务（如数据库、Java 应用）需设置充足的 start_period
• 若未设置，容器可能在初始化完成前即被标记为不健康

卷（Volume）销毁风险

• docker compose down 会保留卷（volumes）
• docker compose down -v 将**删除所有卷**——导致数据丢失
• -v 参数常因教程习惯被误加——在生产环境中会造成灾难性后果
• 命名卷（named volumes）在 down 后仍存在；匿名卷（anonymous volumes）会在 down 时被删除

开发环境中的资源限制

deploy:
  resources:
    limits:
      memory: 512M

• 应在开发阶段即设置资源限制——可尽早暴露内存问题
• 无限制的容器可能耗尽宿主机全部内存，进而导致其他进程被终止
• 将开发中验证过的限制直接复用到生产配置中——避免在生产环境首次发现资源限制问题

.dockerignore

• 若未配置该文件：node_modules、.git、密钥等可能被意外复制进镜像
• 语法与 .gitignore 一致——应与 Dockerfile 放置在同一目录层级
• 过大的构建上下文（build context）会导致构建缓慢、镜像臃肿，并带来潜在安全风险
• 最低建议忽略项：.git、node_modules、.env、*.log 及各类构建产物

覆盖文件（Override File）模式

• docker-compose.yml：通用基础配置，适用于所有环境
• docker-compose.override.yml：自动加载，专用于开发环境（如挂载、端口映射等）
• 生产环境启动方式：docker compose -f docker-compose.yml -f docker-compose.prod.yml up
• 密钥和环境特定配置应放在覆盖文件中，而非基础配置文件中

Profiles 实现可选服务

services:
  mailhog:
    profiles: [dev]

• 声明了 profiles 的服务默认不启动——使 docker compose up 更简洁清晰
• 通过 --profile dev 显式启用
• 典型适用场景：测试数据库、调试工具、模拟服务（mock services）、管理界面等

环境变量优先级

1. Shell 环境变量（最高优先级）
2. Compose 项目目录下的 .env 文件
3. env_file: 指令指定的文件
4. Compose 文件中 environment: 字段定义的变量（对该变量而言优先级最低）

• .env 文件名必须严格为 .env——.env.local 等命名不会被自动加载
• 可通过 docker compose config 命令调试——输出最终解析后的完整配置值