聊到一个所有开发者都绕不开的话题：docker。如果你已经在用，应该体会过“本地跑得好好的，一上测试环境就崩”的痛苦被彻底终结的感觉；如果你还在观望，只需要记住一句话：docker 把应用连同它依赖的整套环境一起打包，让软件在任何机器上都能以完全相同的方式运行。本篇文章我会从核心概念讲起，再到镜像构建、多服务编排，最后整理我在实际项目中踩过的一些坑和优化经验，全程偏实战，适合刚接触容器化的人，也能给已经在用 docker 但想系统理顺原理的读者一些参考。
1. docker到底解决了什么问题：先建立直觉认知
1.1 镜像与容器：一套打包好的运行环境
镜像这个概念如果第一次接触，最容易陷入的误区是把它当成一个压缩包。压缩包解开之后只是文件，而 docker 镜像是一个“带着完整运行环境的文件系统快照”。它包含了你的应用代码、运行时（比如某个版本的 Python、Node.js 或 OpenJDK）、系统依赖库、环境变量和启动命令。
举一个最典型的场景：某个项目需要 Python 3.9 和特定版本的库才能跑，而你同事机器上是 Python 3.13，另一个同事用的是 Python 2.7 维护老项目。过去统一环境靠的是文档，文档里十条注意事项只要有一条漏了就白搭。用 docker 之后，你只需要基于官方镜像构建一个包含全部依赖的镜像，大家拿这个镜像跑出来的环境完全一致，不会再出现“在我这是好的”这种话。
镜像和容器的关系可以理解为面向对象里的类与实例。镜像是静态的模板，容器是模板的运行态。同一个镜像可以启动多个容器，容器之间相互隔离，互不影响。更准确地说，镜像是分层存储的，每一层是一组文件系统的变更记录。这里稍微多说一句：因为分层，所以拉取镜像时如果本地已经有了基础层，就只需要下载新增的层，这也是为什么 docker pull 经常看到“Already exists”的原因。
1.2 数据卷与网络：容器不是孤立的小黑盒
容器是隔离的，这句话容易让人误以为容器里的数据是“一次性”的。其实容器的可写层确实会随着容器删除而消失，所以有状态的数据必须通过数据卷（volume）或 bind mount 挂载到宿主机。数据卷相当于一个宿主机上的持久化目录，容器读写它就像读写本地目录，即使容器被删掉，数据还在。
网络方面，docker 默认提供一个 bridge 网络，容器之间可以通过 IP 或容器名互相访问。对外提供服务时，则需要把容器的端口映射到宿主机上，例如8080:80，含义是访问宿主机的 8080 端口，流量会转发到容器的 80 端口。理解“端口映射”这一点，排查网络问题时思路会清晰很多：报错连不上，先确认是容器内服务没起来，还是端口映射没生效。
这里我建议所有初学者先把“镜像-容器”、“数据卷”、“端口映射”这三组关系想明白，比背命令重要得多。命令是条件反射，模型才是理解问题的地基。
2. 上手实操：从安装到跑起第一个容器
2.1 环境准备与安装选型
安装 docker 本身不难，但不同操作系统差别挺明显。Linux 下面一般直接通过包管理器安装，安装完成后启动守护进程服务。Windows 和 macOS 上则使用桌面版，桌面版内置了一个轻量级虚拟机来运行 Linux 容器。这里需要注意一个常被忽略的点：桌面版运行容器时，文件挂载性能、端口占用、宿主目录权限都可能引发一些奇奇怪怪的报错，很多老手也会在这里被绊住。
安装完成后第一件事不是急着跑容器，而是确认两点：一是docker version能正常输出版本信息，二是docker run hello-world能成功拉取并运行。如果这两步没问题，说明守护进程、镜像仓库连通性都正常。后面所有操作都可以正常进行。
对国内开发者来说，镜像拉取速度是一个现实问题。官方仓库默认位于境外，直接拉取大镜像经常超时。我个人的做法是配置镜像加速器，把daemon.json里的registry-mirrors字段指向一个稳定的镜像源，改完重启 docker 守护进程即可。这个操作基本上属于国内环境使用 docker 的必做项，优先级非常高。
2.2 镜像获取与容器生命周期
学会先拉一个镜像看看：docker pull nginx:alpine。nginx:alpine 这个标签指的是基于 Alpine Linux 构建的 nginx 镜像，体积比默认版本小很多，常用于轻量化部署。拉取完成后用docker images查看本地镜像列表，然后执行：
docker run -d --name web-test -p 8080:80 nginx:alpine这条命令的意思是从 nginx:alpine 镜像启动一个名为 web-test 的后台容器，把宿主机的 8080 端口映射到容器内的 80 端口。执行完后浏览器访问http://localhost:8080，能看到 nginx 默认页面，你的第一个容器就成功跑起来了。
容器的生命周期无外乎启动、停止、重启、删除这几种操作。docker stop web-test会发送停止信号并等待容器优雅退出，docker start web-test再启动它，docker restart web-test则相当于先停再启。需要进入容器内部排查问题时，使用docker exec -it web-test sh，注意这个命令需要容器处于运行状态。容器删除用docker rm web-test，而docker system prune可以清理所有已停止的容器、未使用的网络和悬空镜像，这个命令是我日常清理磁盘空间的常用手段。
2.3 进入容器、查看日志与文件复制
进入容器这一步，很多人犯的错误是总想找一个“像 SSH 一样”的方式。其实不需要，docker exec 就是直接在新开的进程中执行命令。加上-it参数表示分配一个交互式终端，比如docker exec -it web-test sh。需要说明的是，Alpine 镜像里用的是 sh，而 Debian、Ubuntu 镜像里是 bash，进入前先确认镜像自带哪个 shell，不然会得到一条 command not found。
日志查看用docker logs web-test，这是排查容器内部程序报错的第一入口。如果某个容器启动即退出，第一件事就是看日志。-f参数可以持续跟踪日志输出，类似于tail -f，使用 Ctrl+C 退出跟踪。
还有一个非常实用的命令是docker cp，它用于在容器和宿主机之间复制文件。例如把宿主机的配置文件拷进容器：
docker cp ./application.properties web-test:/app/application.properties不过提醒一句：docker cp适合应急排查，不适合作为日常部署手段。正确的做法是把配置通过环境变量、配置中心或数据卷挂载传入，这涉及 Dockerfile 和 Compose 的规范用法，下面详细展开。
3. 让 docker 真正好用：Dockerfile 构建篇
3.1 Dockerfile 核心指令与常见误区
要让自己写的应用被 docker 管理，就得写一个 Dockerfile，它定义了镜像的构建过程。先看一个最小可运行示例：
FROM node:20-alpine WORKDIR /app COPY package*.json ./ RUN npm install COPY . . EXPOSE 3000 CMD ["npm", "start"]逐行说清楚：FROM 指定基础镜像，最好选带标签的官方镜像；WORKDIR 设置了工作目录，后续指令如果使用相对路径都会基于这个目录；COPY 把宿主机文件拷进镜像，第一次单独拷贝 package.json 是合理利用缓存的典型操作；RUN 执行构建时需要运行的命令；EXPOSE 只是声明容器监听端口，真正映射到宿主机要用-p参数；CMD 定义容器启动时执行的命令，只能有一个，可以用 ENTRYPOINT 配合实现更灵活的启动方式。
初学者最容易踩两个坑。第一个是直接把整个项目目录复制进镜像，包括 node_modules、构建产物、日志文件。这不仅拖慢了构建速度，还可能把本地环境特有的文件带进镜像。解决办法是写一个.dockerignore文件，和.gitignore逻辑一样，把该忽略的目录都列进去。
第二个坑是过度使用 RUN 指令。每一条 RUN 都会给镜像增加一层，层数越多，镜像越大，构建越慢。公共经验是：多个连续的命令用&&连接在一条 RUN 里，并且安装完依赖后及时清理缓存，这样镜像体积能显著减少。
3.2 多阶段构建：像流水线一样为镜像减负
构建 Java 项目时需要 Maven 和 JDK，但运行时只需要 JRE 就够了。如果只用单阶段构建，一个镜像里会残留大量编译工具，体积动辄几百 MB。多阶段构建解决的就是这个问题：在第一个阶段使用完整工具链完成编译打包，第二个阶段只拷贝最终产物到干净的运行环境。
下面是一个典型的 Java 项目多阶段 Dockerfile：
FROM maven:3.9-eclipse-temurin-17 AS build WORKDIR /workspace COPY pom.xml . RUN mvn dependency:go-offline COPY src ./src RUN mvn clean package -DskipTests FROM eclipse-temurin:17-jre WORKDIR /app COPY --from=build /workspace/target/app.jar ./app.jar EXPOSE 8080 ENTRYPOINT ["java", "-jar", "app.jar"]第一阶段命名为 build，第二阶段没有名字，只负责拿编译结果。COPY --from=build就是从第一阶段拷贝文件。这个模式可以用在所有有编译步骤的语言上，Node.js 也可以先用 node 镜像执行构建，再把 dist 目录拷到运行镜像里，效果相同。
补充一个经验：多阶段构建不仅能减小镜像，还能减少安全风险，因为最终镜像里没有多余的调试工具、源码和编译器，攻击面变小。刚开始觉得麻烦，熟练之后你会发现几乎所有生产级镜像都应该采用这个模式。
3.3 运行时配置：非 root 用户、时区与镜像安全
很多公开的 Dockerfile 画风是这样的：基础镜像直接以 root 用户运行，应用安装在系统目录，怎么方便怎么来。实际上容器内以 root 运行时，一旦应用被攻破，攻击者就是容器内的最高权限。规范做法是新建一个专用用户：
RUN addgroup -S app && adduser -S app -G app USER app WORKDIR /home/app这里使用的命令是 Alpine 风格的，Debian 系镜像则使用 useradd。注意创建用户在 COPY 之前完成，否则拷贝进来的文件拥有 root 权限，应用可能没有写权限。通过USER指令切换后，容器内的进程将以普通用户身份运行。
时区问题也经常在初次部署时暴露：容器默认 UTC 时间，而业务日志和定时任务必须使用本地时间。简单的办法是在 Dockerfile 里设置环境变量：
ENV TZ=Asia/Shanghai但需要确保基础镜像包含了时区数据，如果镜像比较精简，可能还需要额外安装 tzdata 包。另一种方式是运行时通过-e TZ=Asia/Shanghai传入同一环境变量，效果一样。这个细节很容易被忽略，但等调度任务出现“凌晨三点没跑”的告警时，你大概率会最先怀疑它。
4. docker compose：一键把多个容器变成一套服务
4.1 为什么需要 compose 而不是一条条 docker run
单个容器用 docker run 没问题，但现实中的系统往往由多个组件组成：前端、后端、数据库、缓存。如果依次手敲 docker run，参数又长又容易写错，而且多个容器在哪个网络下通信、依赖关系先后顺序都是麻烦事。
docker compose 的价值在于把整套服务的定义写在一个 YAML 文件里，一条命令完成构建、启动、停止。它不是容器调度平台，只是单机编排工具，但足够覆盖大多数开发环境和中小型项目的部署需求。
先看一个实际示例，假设有一个使用 Spring Boot 的服务和一个 MySQL 数据库：
version: "3.8" services: db: image: mysql:8.0 environment: MYSQL_ROOT_PASSWORD: rootpass MYSQL_DATABASE: appdb volumes: - db-data:/var/lib/mysql restart: always app: build: context: . dockerfile: Dockerfile depends_on: - db ports: - "8080:8080" environment: SPRING_DATASOURCE_URL: jdbc:mysql://db:3306/appdb restart: always volumes: db-data:重点看几个细节。服务之间通过服务名通信，app 里访问数据库用的是db:3306，docker compose 会自动创建默认网络，容器在这个网络内可以通过服务名解析到对应 IP，不需要写死内网地址。depends_on控制启动顺序，但要注意它只保证服务先启动，不保证数据库初始化完成，真实的完整处理需要借助健康检查或重试机制。
volumes底部的db-data声明了一个命名卷，数据库的数据存储在里面，即使在 compose 环境下执行docker compose down，数据卷默认也不会被删除，这个设计很重要，误删数据的事故大多发生在没有理解这条规则的时候。
4.2 compose 文件关键配置说明
一个 compose 文件里最常用的顶层字段就三个：services、volumes、networks。services 下面每一个子项就是一个容器服务，命令里 build 和 image 二选一或同时存在。同时存在时，构建后的镜像会以 image 指定的名称保存，后续可以直接复用。
常用参数里，environment和env_file都是注入环境变量的方式，区别在于前者直接把键值写在文件里，后者从外部文件加载，适合存敏感信息。ports和expose的区别也容易混淆：ports 会把端口暴露给宿主机，expose 则仅声明容器端口对 compose 网络内的其他服务可见，外部访问不到。
资源限制也建议在 compose 里配置，用deploy.resources.limits设置容器的 CPU 和内存上限，避免某个服务出现内存泄漏时直接把宿主机打爆：
deploy: resources: limits: cpus: "0.50" memory: 512M4.3 日常运维操作与保留策略
compose 提供了自己的命令体系，日常使用频繁的是这几个：docker compose up -d启动整套服务，docker compose down停止并删除容器，docker compose logs -f跟踪多个服务的日志输出，docker compose exec app sh进入特定容器。
此处有个特别实用的经验：改完某个服务的配置后不需要把整套服务全部重建，用docker compose up -d app只启动或重建 app 这个服务，配合--build参数可以在代码变更后重新构建镜像。这样既能节省时间，也能减少不必要的容器重启。
需要清理整套服务产生的数据时，docker compose down -v会在停止服务的同时删除所有声明的数据卷，这也是唯一一个需要谨慎操作的命令。数据卷一旦删除无法找回，执行前务必确认有没有需要备份的数据。
5. 踩坑经验与排查技巧：这些坑我不希望你踩一遍
5.1 磁盘空间暴涨：镜像层、悬空镜像与构建缓存
docker 用久了，磁盘占用急剧上升是非常普遍的现象。拉取的镜像不会自动删除，项目迭代过程中反复构建会产生大量悬空镜像（标签为 none 的镜像），构建缓存也会累积占用大量空间。
排查空间占用的命令是docker system df，它会告诉你镜像、容器、数据卷、构建缓存各自占了多大空间。清理操作按照风险从低到高排列：docker image prune清理悬空镜像，docker builder prune清理构建缓存，docker system prune -a --volumes则会把所有未使用的镜像、容器、网络和数据卷一并清理，属于“核弹级”命令，谨慎使用。
还有一个细节：日志文件也可能占满磁盘。容器打印的日志会写入宿主机的/var/lib/docker/containers目录，如果不限制大小，一个无限打的循环日志就能把分区写满。解决办法是启动时加参数限制日志：
--log-opt max-size=10m --log-opt max-file=3或者在 daemon.json 里统一配置，这个动作应该在真正出问题之前就完成。
5.2 容器时区、中文乱码、用户权限问题
时区问题前面提过解决办法，这里再补充一个更隐蔽的坑：某些镜像不只是缺时区数据，连 locale 都没有，Java 类应用容易出现中文乱码或字符编码问题。可以在 Dockerfile 里显式安装 locales 并设置 LANG，虽然对纯 Linux 容器影响不大，但对运行 Java、Python 这类重视编码的运行时是必需的。
用户权限问题常见于挂载宿主机目录后，容器内进程写的文件在宿主机上属于 root，导致宿主机上其他用户无法删除或修改。我常用的解决办法是让容器内的进程以宿主机当前用户的 UID 运行：docker run --user $(id -u):$(id -g)，或者在 compose 文件里指定：
user: "1000:1000"这样容器产生的文件归属就是当前用户，不会有后续清理上的麻烦。
5.3 网络模式与性能优化心得
docker 默认的 bridge 网络适合大多数场景，但要求低延迟、高吞吐的服务，尤其是网络密集型的应用，bridge 网络自带的 NAT 转发会有少许性能损耗。此时可以考虑直接使用宿主机网络模式：
docker run --network host网络栈直接共享宿主机的，没有端口映射的额外开销。代价是失去了端口隔离能力，容器里监听的端口直接占用宿主机端口。本地调试场景我用得比较多，生产环境则取决于具体的网络策略。
性能优化方面还有一个容易忽略的点：镜像仓库的拉取速度直接影响服务扩容时间。在 CI 流水线里构建镜像后推到仓库，生产机器从仓库拉取，网络效率决定整个发布流程的快慢。除了加速器，合理利用镜像分层也能显著提升拉取速度——经常变动的代码放在靠后的层，稳定不变的依赖放在靠前的层，别人拉取时只要能复用前面的层，就能省大量流量和时间。
5.4 进程管理与僵尸进程
容器必须有一个前台进程，如果镜像里的启动命令是后台启动，容器会立刻退出。例如在容器里执行service nginx start，它启动后命令返回，PID 1 进程结束，容器自然跟着退出。正确做法是让服务以阻塞方式运行，比如直接执行nginx -g "daemon off;"。
还有一个容易被忽视的问题是 PID 1 进程的信号处理。常规的 init 系统会负责回收子进程和处理信号，但容器里的 PID 1 就是你的应用进程，它如果不正确处理 SIGTERM，容器的优雅停止可能失效，应用也来不及清理状态。对 Node.js 应用，我习惯在启动命令里加入 tini 或使用自带信号处理的运行方式，可以避免很多诡异的“容器停不掉”的问题。
最后补几句使用心得
我在实际项目里最大的体会是：docker 的学习曲线并不陡峭，真正难的是理解它的边界和习惯。它很适合跑无状态服务，数据库这类有状态的组件部署在容器里虽然可行，但需要格外关注数据卷和性能损失，有时候使用托管数据库服务反而是更省心的选择。调试容器问题时，不要急着 Google 报错信息，先看docker logs、docker inspect和宿主机的系统日志，大部分问题在这三步之内就能定位。这个领域工具更新快，新版本会带来新特性，也会淘汰旧习惯，保持手上的镜像更新到较新的稳定版本，至少能避开不少已经修过的历史问题。
