多文件拆分下，服务容器应复用全局配置：volumes和networks必须集中定义于base.yml，覆盖文件仅引用名称；服务配置按字段逻辑叠加（environment覆盖、ports追加、volumes替换）；通过.env变量注入实现路径与参数动态化；上线前须用config命令验证合并结果。
多文件拆分下，服务容器要能稳定复用全局配置（如 networks、volumes、共享环境变量），关键不是“每个文件都写一遍”，而是建立清晰的职责边界：基础资源统一定义，服务配置专注行为，环境差异靠引用和注入。
基础资源必须集中定义
volumes 和 networks 是基础设施，不是服务属性。它们一旦分散定义，就会在多文件合并时被后加载文件覆盖或清空——比如只写 volumes: [db_data] 而不带 driver_opts，Docker Compose 会把它当成空声明，把 base 里完整的定义整个抹掉。
- 所有
volumes和networks只出现在docker-compose.base.yml中，包含完整参数（如 NFS 类型、bridge 驱动） - dev/prod 等覆盖文件中，只在
services.xxx.volumes或services.xxx.networks字段里写名称（如- db_data或- app-net），绝不重复声明同名资源 - 若某环境需额外卷（如 prod 的备份卷），新建唯一名称（如
db_backup_prod），并在对应服务中显式引用
服务配置只做“叠加”不做“重写”
服务本身（image、ports、environment 等）可以按需覆盖，但要理解不同字段的合并逻辑：
-
environment：同名变量被后文件覆盖，其余保留；适合 dev 加DEBUG=1，prod 加ENV=production -
ports：列表项追加，不是替换；base 写- "80:80"，dev 可再加- "8080:8080"调试端口 -
volumes（挂载项）：列表完全替换；所以 dev 想挂载本地代码，就直接写- ./src:/app，它会替代 base 里的生产挂载路径 -
deploy.resources：整块替换；prod 文件中定义 CPU/memory 限制，会彻底取代 base 中的默认值
用 .env + 变量注入实现路径与参数动态化
宿主机路径、数据库地址、日志级别等易变参数，不能硬编码在 YAML 里。统一交给 .env 控制：
- 在
.env中设DB_HOST_PATH=./data，prod 环境用.env.prod设DB_HOST_PATH=/mnt/db - base 文件中写
volumes: - ${DB_HOST_PATH}:/var/lib/mysql，启动时指定--env-file .env.prod - 敏感值（如密码）也可用
env_file单独引入，避免泄露到 git 或日志中
验证合并结果是上线前必做动作
运行 docker compose -f base.yml -f prod.yml config，直接输出最终生效的完整配置。重点检查：
-
volumes和networks节点是否完整，有没有意外缺失（说明某文件做了空覆盖） - 各服务下的
volumes列表是否符合预期（dev 有本地挂载，prod 用绝对路径） -
environment是否正确叠加，没遗漏关键变量
