docker compose 多镜像版本管理需结构化约定：禁用 latest，强制语义化版本标签；拆分配置文件（base/prod/dev等）按环境隔离；部署时加 --pull always 或清理后拉取；高要求场景用 digest 锁定镜像。
直接用 Docker Compose 管理多镜像版本，关键不是“选对命令”，而是把版本控制落到配置里、流程里、部署动作里。混乱往往来自“没约束的 latest”和“靠人记版本”，解决它不靠技巧，靠结构化约定。
明确镜像标签策略，禁用 latest 用于生产
所有服务镜像必须使用语义化版本（如 v1.2.3 或 20260615-abc7f2e），禁止在 docker-compose.yml 中写 latest。例如：
- ✅ 正确：
image: guiji2025/fish-speech-ziming:v1.4.0 - ❌ 危险：
image: guiji2025/fish-speech-ziming:latest
这样做的好处是：每次 docker-compose up 拉取的镜像是确定的；回滚只需改一行标签；CI/CD 流水线可自动校验 tag 格式（比如用正则 ^v[0-9]+\.[0-9]+\.[0-9]+$）。
拆分配置文件，按环境+用途隔离版本组合
不要只靠一个 docker-compose.yml 打天下。参考 HeyGem.ai 的实践，把配置按实际场景物理分离：
-
docker-compose.base.yml：定义通用服务结构、网络、卷（不含镜像版本） -
docker-compose.prod.yml：指定生产用镜像版本、资源限制、健康检查 -
docker-compose.dev.yml：用调试版镜像（如v1.4.0-debug）、挂载源码、开日志 -
docker-compose-5090.yml：仅覆盖 GPU 相关配置（runtime: nvidia、deploy.placement.constraints）
启动时组合使用：docker-compose -f docker-compose.base.yml -f docker-compose.prod.yml up -d。这样不同环境的镜像版本互不干扰，也不会误把开发镜像推到生产。
统一拉取行为，避免本地缓存引发版本错乱
即使配置写了固定版本，Docker 仍可能因本地已有旧镜像而跳过拉取。务必在部署前强制刷新：
- 加
--pull always参数：docker-compose up --pull always -d - 或先清理再启：
docker-compose down && docker-compose pull && docker-compose up -d
同时配置国内镜像源（如 https://docker.zhai.cm），防止因网络问题导致部分镜像拉取失败、部分成功，造成混合版本运行。
用 digest 锁定镜像，彻底杜绝 tag 覆盖风险
最严格的版本控制方式：不用 tag，改用镜像 digest（SHA256 哈希值）。它指向唯一构建产物，哪怕 tag 被覆盖也不会变：
- 构建后查 digest：
docker inspect --format='{{.RepoDigests}}' guiji2025/fun-asr:v1.1.2 - 写入 compose：
image: guiji2025/fun-asr@sha256:abcd1234...
适用于对一致性要求极高的生产环境。CI 流水线可在推送成功后自动提取 digest 并注入部署清单，实现全自动、不可篡改的版本锚定。
