Docker自2013年以来一直在生产中使用。到2026年，它是基础设施——不再是一个新颖的工具，而是开发和部署堆栈的标准部分。以下是开发者实际上如何使用它，超过教程级别。
Docker解决的核心问题
“在我的机器上能运行”是Docker构建来消除的问题。在容器之前：操作系统、已安装库、环境变量和依赖版本的差异导致在开发中工作的代码在生产中失败。Docker容器将应用程序代码与所有依赖项（操作系统库、运行时版本、配置）打包成一个隔离、可重现的单元。在开发者MacBook上构建的Docker镜像在数据中心的Linux服务器上完全相同地运行。容器运行时（底层技术）由containerd（Docker的运行时）或CRI-O（由Kubernetes使用）提供。Docker Desktop是通过轻量级Linux虚拟机在Mac和Windows上运行容器的开发者工具。
Dockerfile
Dockerfile是构建镜像的配方。重要的实用模式：多阶段构建（在一个阶段构建应用程序，只将输出二进制文件复制到最小的最终镜像中——大幅减少镜像大小）；层缓存（Docker缓存每个指令层；将频繁更改的指令放在最后以避免缓存未命中）；非root用户（在容器内以root身份运行是安全风险；使用`RUN useradd -m appuser && USER appuser`创建专用用户）；最小基础镜像（`python:3.12-slim`而不是`python:3.12`将镜像大小减少约150MB）。一个结构良好的Python Dockerfile：`FROM python:3.12-slim AS builder`，复制requirements.txt并`RUN pip install`，然后`FROM python:3.12-slim`，只从构建器阶段复制已安装的包和应用程序代码。生成的镜像比简单的单阶段镜像显著更小，CVE漏洞也更少。
用于本地开发的Docker Compose
Docker Compose是大多数开发者花费大部分Docker时间的地方。`docker-compose.yml`定义了构成本地开发环境的服务（应用程序、数据库、缓存、消息队列）。关键模式：带健康检查的`depends_on`（确保数据库在应用程序启动之前实际上已准备就绪，而不仅仅是容器在运行）；代码的卷挂载（将本地代码目录挂载到容器中，这样更改会立即反映，无需重建）；来自.env文件的环境变量（使用`env_file: .env.local`将秘密与compose文件分离）。常见的反模式：在开发中为每次代码更改构建类似生产的Docker镜像——改用卷挂载代码和热重载开发服务器。
从开发到生产
容器注册表：Docker Hub（公共）、AWS ECR、Google GCR、GitHub容器注册表——将构建的镜像推送到注册表；拉取以部署。在生产中，通常不直接使用Docker——Kubernetes（k8s）或托管容器服务（AWS ECS、Google Cloud Run、Azure容器实例）大规模编排容器。Cloud Run特别受到简单部署的欢迎：推送容器镜像，谷歌管理扩展，你按请求付费，零到零扩展（不接收请求时无成本）。小团队从开发到生产的常见路径：本地Docker Compose → CI/CD构建并推送镜像 → Cloud Run或ECS拉取并部署镜像。这个管道比Kubernetes更快设置，对许多生产工作负载来说已足够。
