Docker通过“依赖打包+部署隔离”双机制解决依赖冲突：打包将应用及专属库、配置固化进镜像，隔离使各容器拥有独立文件系统与进程空间，互不干扰。
Docker 通过“打包+隔离”双机制，从根本上规避软件依赖冲突。它不靠在宿主机上反复安装/卸载库，而是把每个应用连同它专属的运行环境（含指定版本的库、工具、配置）一起封进独立容器里——不同应用用不同版本的 OpenSSL、Python 或 JDK，互不干扰。
依赖打包：把所有需要的东西“自带入场”
传统部署中，多个应用共享系统级依赖，比如 A 应用要 Python 3.9 + numpy 1.22，B 应用要 Python 3.11 + numpy 1.25，装在一起极易报错。Docker 的解法是：在 Dockerfile 中明确声明所需依赖，并在构建镜像时一并安装。
- 用 RUN apt-get install -y libpq-dev 或 RUN pip install -r requirements.txt 把依赖固化到镜像层
- 这些依赖只对当前镜像生效，不会写入宿主机系统
- 镜像一旦构建完成，就自带完整运行栈，换机器运行也不用重新配环境
运行隔离：每个容器拥有独立的文件系统与进程空间
即使两个容器都装了 MySQL 客户端，只要它们基于不同基础镜像（如 ubuntu:22.04 和 alpine:3.19），各自链接的 C 库路径、符号版本都完全分离。操作系统内核被复用，但用户空间（/usr/lib、/etc、环境变量等）彼此不可见。
- 容器间默认无法访问对方的 /lib 或 /opt 目录
- 同一端口（如 5432）可被多个容器同时监听，因网络命名空间隔离
- 避免了 “Ubuntu 编译的二进制在 CentOS 上找不到 libc.so.6” 这类跨发行版兼容问题
构建阶段控制：用 --no-cache 和多阶段切断缓存污染
依赖冲突常隐藏在构建缓存里：比如第一次用 pip install 装了旧版包，后续 requirements.txt 升级了但 Docker 复用旧缓存层，导致实际没更新。这时需主动干预：
- 加 --no-cache 参数重建镜像：docker build --no-cache -t myapp .，强制跳过所有缓存层
- 对编译型项目（如 Java/Go），采用多阶段构建：第一阶段用 maven:jdk-17 编译，第二阶段仅复制编译产物到 slim-jre 镜像，彻底剥离构建工具和冗余依赖
- 将 COPY requirements.txt . 单独成行，让 pip 安装步骤能精准利用缓存（仅当该文件变化时才重装）
环境一致性：从开发到上线不再“在我机器上能跑”
依赖冲突往往爆发在环境迁移时——本地 Mac 装了 Homebrew 的 OpenSSL，测试机是 CentOS 用 yum 装的，生产是 Alpine。Docker 消除了这个断层：
- 开发者写好 Dockerfile，定义好 FROM python:3.10-slim 和 pip install 步骤
- CI 流水线执行相同 build 命令，产出完全一致的镜像 ID
- 运维只需 docker run 该镜像，无需关心宿主机装了什么版本的 curl 或 gcc
