Docker
把应用和运行环境一起打包，到哪都能一样跑
Docker 用镜像把“代码 + 依赖 + 系统库 + 配置”打成一层层只读包，运行时加一个可写层就是容器。它共享宿主机内核，所以启动是秒级、一台机器能跑几十上百个，比虚拟机轻得多。
它解决什么问题
本地跑得好好的，上了测试环境就报“缺库、版本不对”；一台服务器部署三个应用，依赖版本互相打架。
真实场景：典型场景：Dockerfile 写清 JDK 版本和启动命令，build 出镜像推到仓库，测试、预发、生产拉同一个镜像跑，环境差异归零。
核心概念
每个概念一句话 + 一个类比。点击卡片看更详细的解释。
数据流转动画
跟着步骤看一条数据从进入系统到被处理完的完整路径，可以暂停、重播和调速。
从 Dockerfile 到运行中的容器
← 左右滑动查看完整流程图 →
FROM openjdk:17、COPY app.jar、ENTRYPOINT java -jar，每条指令一层。
提示：镜像分层是复用的关键：只改最后一层，前面的层都能命中缓存。 悬停图中的节点可以看概念解释。
优劣势
短句说清适合什么、不适合什么，选型时先看这一栏。
- 环境一致，彻底解决“我这能跑”
- 秒级启动，一台机器可跑很多实例
- 镜像分层复用，构建和分发高效
- 生态成熟，CI/CD、K8s 都以它为基石
- 共享宿主机内核，隔离性弱于虚拟机
- Windows 容器生态和 Linux 差异大
- 镜像体积容易失控，需要多阶段构建
- 有状态服务（数据库）容器化要额外考虑存储
常见使用场景
每个场景都配一句「为什么用它」。
统一开发环境
docker compose 一键起 MySQL、Redis、ES，新人不用装一堆软件。
为什么用它：依赖版本写在 compose 文件里，团队完全一致。
CI/CD 构建产物
流水线里 build 镜像，各环境用同一个 tag 部署。
为什么用它：构建一次，处处运行，回滚就是换 tag。
微服务部署单元
每个服务一个镜像，配合 K8s 编排。
为什么用它：镜像是最小可部署单元，天然适合弹性伸缩。
同类对比
和同赛道的组件并排看，差异一目了然。
容器不是「更轻的虚拟机」，它根本不虚拟硬件。需要强隔离时虚拟机仍然不可替代。
常见问题
上手第一个月最容易卡住的地方。
Q1和虚拟机的区别？
虚拟机虚拟化硬件、跑完整操作系统，启动分钟级、占用 GB 级内存；容器共享宿主机内核，只隔离进程/网络/文件系统，启动秒级、占用 MB 级。隔离性虚拟机更强。
Q2镜像和容器的关系？
镜像是类，容器是实例。一个镜像可以启动多个容器，每个容器有自己的可写层，互不影响。删容器不会删镜像。
Q3容器里的数据会丢吗？
会。可写层随容器删除而消失。数据库、上传文件必须挂 Volume 或绑定宿主机目录。
Q4镜像怎么减小体积？
用 alpine/slim 基础镜像、多阶段构建（build 阶段和运行阶段分离）、合并 RUN 指令减少层数、.dockerignore 排除无关文件。