镜像和容器是模板与实例的关系：镜像是只读静态打包，容器是其可写运行实例；所谓“版本冲突”实为操作误用，需通过明确标签、清理悬空镜像、统一docker环境等手段规范管理。
镜像和容器不是“冲突关系”，而是“模板与实例”的关系：镜像是一份只读的、静态的软件打包（含代码、依赖、配置），容器是它运行起来的动态实例。所谓“版本冲突”，实际是操作层面的误解或误用，比如多个容器依赖不同版本镜像却共用同一标签、本地镜像过时、或 docker 本身存在多版本混装。解决重点不在“消除冲突”，而在厘清来源、统一管理、避免覆盖。
明确镜像来源与标签含义
同一个镜像名（如 nginx）不等于同一内容——nginx:latest 可能每周更新，nginx:1.25.4 才是确定版本。若开发环境拉的是旧版 latest，生产环境拉到新版，就会出现行为不一致。
- 始终使用带明确语义化版本或哈希值的标签，例如 redis:7.2.5 或 python@sha256:abc123...
- 避免在生产部署中使用 :latest，它不可追溯、不可复现
- 通过 docker images 查看本地镜像的 REPOSITORY 和 TAG 列，确认是否真为预期版本
清理本地冗余镜像与悬挂层
构建或拉取过程中残留的中间层、未打标签的悬空镜像（dangling image），可能干扰版本识别，甚至让 docker rmi 报错“被容器引用”。
- 列出所有悬空镜像：docker images -f "dangling=true"
- 安全清理未使用镜像：docker image prune（仅删悬空）或 docker image prune -a（删所有未被容器引用的镜像）
- 注意：prune -a 会删除所有未运行容器所依赖的镜像，请先确认无长期离线容器依赖旧镜像
统一 Docker 环境与安装方式
真正的“版本冲突”常来自宿主机上 Docker 引擎自身多版本并存，例如 apt 安装的旧版 + 官方脚本安装的新版，导致 docker --version 和 docker version 显示不一致，或 dockerd 后台服务异常。
- 检查是否多版本共存：which docker、dpkg -l | grep docker（Ubuntu）或 rpm -qa | grep docker（RHEL/CentOS）
- 彻底卸载旧版（如 Ubuntu）：sudo apt-get purge docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
- 改用 Docker 官方源安装，确保 dockerd 和 CLI 版本严格匹配
容器内不删镜像，改用重建策略
有人试图在容器里执行 docker rmi，这是错误场景——容器内没有 Docker daemon，且镜像属于宿主机。所谓“容器内镜像冲突”，本质是容器启动时指定了错误镜像，或挂载了旧配置。
- 停止并删除问题容器：docker stop myapp && docker rm myapp
- 确认目标镜像已正确拉取：docker pull nginx:1.24.0
- 用明确镜像+新容器名重启：docker run -d --name myapp-v2 nginx:1.24.0
- 如需保留数据，用命名卷或绑定挂载，而非依赖容器内部状态
