核心是通过镜像固化运行时、依赖、配置和启动逻辑，实现“构建一次，到处运行”；需统一基础镜像、显式声明版本、环境变量驱动配置、分环境编排、ci/cd中构建推送唯一镜像，并校验底层配置一致性。
用 Docker 实现开发、测试、生产环境完全一致，核心不是“装个 Docker 就行”，而是通过镜像固化运行时、依赖、配置和启动逻辑，让同一份镜像在三套环境中以相同方式运行。关键在于“构建一次，到处运行”——但前提是构建过程本身也要受控、可复现。
统一基础镜像与运行时环境
避免开发用 macOS、测试用 Ubuntu、生产用 CentOS 导致的兼容问题。所有环境都基于同一个官方基础镜像（如 python:3.11-slim 或 node:20-alpine），并在 Dockerfile 中显式声明：
- 固定语言版本（不写
python:3，而写python:3.11.9-slim） - 用
apt-get install -y --no-install-recommends或apk add --no-cache安装系统依赖，避免隐式差异 - 禁止在容器内手动安装包或修改文件——所有变更必须进 Dockerfile + 构建
配置与代码分离，环境变量驱动行为
数据库地址、API密钥、日志级别等不能硬编码，也不能靠不同环境改源码。Docker 启动时通过 -e 或 --env-file 注入变量，应用内部统一读取 os.environ 或 process.env：
- 开发：用
docker run -e DB_HOST=localhost -e DEBUG=true ... - 测试/生产：用环境变量文件（
.env.test,.env.prod）配合 CI/CD 自动挂载 - 敏感信息不进镜像也不进 Git，用 Docker Secrets（Swarm）或外部 Vault（K8s）管理
用 docker-compose.yml 定义服务拓扑，但分环境维护
单个 docker-compose.yml 不够——开发需要本地 MySQL 容器，生产却连 RDS。推荐按环境拆分：
-
docker-compose.base.yml：共用服务定义（如 app 的 build、volumes、healthcheck） -
docker-compose.dev.yml：加depends_on本地 db、redis，映射源码目录（./src:/app/src）用于热重载 -
docker-compose.prod.yml：关闭 dev 工具，启用多副本、资源限制、日志驱动，挂载只读配置卷 - 启动时合并：
docker compose -f docker-compose.base.yml -f docker-compose.prod.yml up -d
CI/CD 流水线中构建并推送唯一镜像
开发机器上 docker build 出来的镜像不可信——本地缓存、不同 Docker 版本、宿主机工具链都会影响结果。必须在 CI 中完成：
- 每次提交触发构建，用 Git SHA 或语义化版本（如
v1.2.3）打镜像标签 - 构建后推送到私有 Registry（如 Harbor）或云服务（ECR/ACR），镜像名格式如
myapp:5a7b2c1 - 测试环境拉取
myapp:5a7b2c1部署；生产也拉同一镜像，不重新构建 - 禁止使用
latest标签——它破坏可追溯性，无法回滚到确切版本
不复杂但容易忽略：环境一致 ≠ 镜像一致，还取决于网络模型（host/bridge）、存储驱动（overlay2/devicemapper）、cgroup v1/v2 等底层配置。生产集群建议统一 Docker 版本和内核参数，用 docker info 和 docker version 定期校验。
