Docker 怎么用

0030 秒速览：三句话、一张处境表、两个数字

读完这一篇，你能干成三件具体的事：在自己机器上装好 Docker 并能跑起来、把自己写的项目打包成一个可以到处搬的镜像、以及把这个镜像用四种方式之一送给别人——包括"他那边一条命令就跑起来"的那种。它不教你 Linux 系统管理，也不讲 Kubernetes（管理成百上千个容器的另一套工具，跟本文不是一回事）。

按你现在的处境，直接跳到那一节

先记住两个数字

这四个数字解决新手最常见的两个恐慌："Docker 是不是很占磁盘"（看第一个），以及"我拉镜像怎么被限速了"（看第四个）。镜像体积的更多数字与出处见 04.6。

01它是什么、解决什么问题：从一个你肯定遇到过的场景说起

先看现场：为什么"在我电脑上能跑"是一句废话

你写了一个小网站，在自己电脑上跑得好好的。你把它发给朋友——他那边报错。你们对着屏幕排查两小时，最后发现是：他的 Python 是 3.9，你的是 3.13；他少装了一个包；你代码里写了一个只在 Mac 上存在的路径。

这不是谁水平不行，这是"环境"这件事本身的问题。你的项目要跑起来，除了代码，还依赖一大堆代码之外的东西：语言版本、依赖包、系统库、环境变量、目录路径。这些加起来叫运行环境。

传统解法是"写一份安装文档，让对方照着配"。问题是：文档会过期、机器会不一样、没人愿意照着一份二十步的文档配环境。Docker 的思路是换个方向——既然环境太难复制，那就把环境和代码一起打包，做成一个能整体搬运的东西。

盒子、正在跑的盒子，和一句话的官方定义

Docker 把项目打包成的那个东西叫镜像（image）。官方对它的定义是一句值得背下来的话：

这句话里最该抓住的词是 read-only（只读）。镜像做好之后就锁死了，你没法"进去改一改"——想改只能重新做一份新的。而容器（container）是另一回事，官方的定义是 "A container is a runnable instance of an image"——容器是一个镜像跑起来的实例。

打个比方（这个比方后面会用到）：

• 镜像像一张系统安装盘——刻好了就是刻好了，改不了，但你可以拿它装出一台台机器；
• 容器像按这张盘装好并开机的那台机器——可以开机、可以往里写东西、可以关掉、可以直接扔掉；
• 同一张盘可以装出很多台机器——同一个镜像可以同时跑出好几个容器，它们互不干扰。

它不是虚拟机——四个最常见的错想，一次破掉

"Docker 就是虚拟机吧？"这是新手最常见的理解，也是最诱人的一个误解：两者都给人"隔离出一个独立环境"的感觉，而且都要求你先装一个不小的软件。但它们在原理上完全不同。

官方对这条边界的表述很直接（docs.docker.com）："If you run multiple containers, they all share the same kernel, allowing you to run more applications on less infrastructure."——多个容器共用同一个内核，所以能在更少的硬件上跑更多应用。

顺着"共用内核"这条线，四个错想就都能破解了：

"装 Docker"到底装了什么：一个客户端，一个干活的

你敲的 docker 命令本身不会打包、不会运行任何东西——它只是把你的话转述给一个在后台常驻的"干活程序"。这个结构叫客户端-服务端（client-server）：

官方对这个"干活的"有个名叫 dockerd 的进程（daemon，守护进程：在后台一直跑着、不跟你直接打交道的程序），它 "listens for Docker API requests and manages Docker objects"，也就是接收请求、管理镜像和容器这些对象。

为什么这点值得单独讲？因为新手最常见的一类报错——Cannot connect to the Docker daemon——意思就是"客户端还在，但干活的没在跑"。你敲的命令没错，是后台那个程序没起来。记住这个结构，这类报错以后你会自己判断。

验证这个结构最直接的一条命令是 docker version，它会把 Client 和 Server 两段分别打出来：只看得到 Client 段、Server 段报错，说明客户端在、后台没起来。而 docker --version 只打一行客户端版本号，看不出后台死没死。

那 Docker Desktop 又是什么？

你在 Mac 或 Windows 上装的那个带图形界面的大块头，叫 Docker Desktop。它不是"另一个 Docker"，而是一个把整套东西打包在一起的安装包。看它的官方发布说明最清楚（Docker Desktop 4.91.0，2026-09-14）里面装的是：

在 Mac 和 Windows 上，这个包里还额外含一个小型的 Linux 虚拟机。原因就是上面说的"共用内核"：Mac 和 Windows 的内核不是 Linux，跑不了 Linux 容器，所以必须在中间垫一个真的 Linux。你平时感觉不到它的存在，但下面几件事都是它的表现：

• Mac 上 Docker Desktop 必须开着，docker 命令才能连上后台（这是最常见的"我命令没错啊"）；
• Mac 上没有 dockerd 的官方独立安装——官方静态二进制在 macOS 上只发客户端，"No dockerd is included; you supply a runtime elsewhere"（docs.docker.com）；
• Linux 上没有这层虚拟机，所以 Linux 也能反过来装 Engine 本体。

02怎么装：五种装法，先对号入座

Docker 的安装方式之所以看起来乱，是因为它在不同平台上装的根本不是同一个东西：Mac 和 Windows 上装的是 Docker Desktop（内含引擎），Linux 服务器上装的是 Docker Engine 本体。先看这张表，再往下找你那一行。

02.1 Mac：Docker Desktop，两种装法

装法一：下载 .dmg 图形安装（官方文档给的路径）。官方页面提供两个独立下载：一个是给 Apple 芯片（M 系列）的，一个是给 Intel 芯片的——下错了不是装不上，是会跑得很难受。装法就是双击 Docker.dmg，把 Docker 图标拖进 Applications 文件夹。

装法二：Homebrew，一条命令：

brew install --cask docker-desktop

另外两条官方给出的硬要求：至少 4 GB 内存；Apple 芯片上 Rosetta 2 现在是"推荐"而非必需（"no longer strictly required"）。手动装可以用 softwareupdate --install-rosetta。

02.2 Windows：Docker Desktop，先看清门槛

Windows 上的要求比 Mac 具体得多，而且版本不对是装不上的。官方列出的门槛（docs.docker.com）：

• 系统：Windows 10 64 位企业版/专业版/教育版 22H2（build 19045），或 Windows 11 64 位企业版/专业版/教育版 23H2（build 22631）及以上；
• 不支持的两种情况：服务器版 Windows（"Docker Desktop is not supported on server versions of Windows"）；以及 Home 版只能跑 Linux 容器，不能用原生的 Windows 容器；
• WSL 版本 2.1.5 或更高（若要用 Enhanced Container Isolation 则需 2.6+）。WSL2 是 Windows 上的"Linux 子系统"——微软提供的一台轻量 Linux，Windows 上的 Docker 就是靠它跑起来 Linux 容器的；
• BIOS/UEFI 里开启硬件虚拟化（CPU 上那项"允许跑虚拟机"的功能，多数机器默认是开的），至少 8 GB 内存。

装法：官方给的是安装器（Docker Desktop Installer.exe）与 Microsoft Store。命令行静默安装的写法是：

"Docker Desktop Installer.exe" install --user

如果你习惯用 winget，包标识符是 Docker.DockerDesktop：

winget install -e --id Docker.DockerDesktop

还有一条容易忽略的规则：要用原生 Windows 容器，必须用 all-users 模式安装（"Windows containers are only supported in all-users installation mode."），也就是安装时不能加 --user。默认模式跑的是 Linux 容器。

02.3 Linux：官方 apt / dnf 仓库，命令全给你

Linux 上装的是 docker-ce——Docker 官方仓库里那个引擎包。注意一个陷阱：Ubuntu 自带的仓库里也有个叫 docker.io 的包，官方把它归为 "unofficial packages"，装官方仓库之前要先卸掉，否则会打架。

Ubuntu / Debian（现代 deb822 写法）

官方文档现在用的是 /etc/apt/sources.list.d/docker.sources 这种新格式，不再是老教程里那行 docker.list。以下整段可直接复制：

# 1. 先卸掉发行版自带的、会和官方包打架的那些
sudo apt remove $(dpkg --get-selections docker.io docker-compose docker-compose-v2 \
  docker-doc docker-buildx podman-docker containerd runc | cut -f1)

# 2. 装基础工具，把官方签名密钥放好
sudo apt update
sudo apt install ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

# 3. 加官方仓库（Ubuntu；Debian 把 ubuntu 换成 debian，Suites 那行用 $VERSION_CODENAME）
sudo tee /etc/apt/sources.list.d/docker.sources <<EOF
Types: deb
URIs: https://download.docker.com/linux/ubuntu
Suites: $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}")
Components: stable
Architectures: $(dpkg --print-architecture)
Signed-By: /etc/apt/keyrings/docker.asc
EOF

# 4. 装
sudo apt update
sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

注意最后一行五个包的分工：docker-ce 是引擎本体，docker-ce-cli 是你敲的命令，containerd.io 是更下层拉起容器的运行时，后两个分别是 buildx（造镜像）和 compose（多容器）插件。少装后两个，你后面敲 docker compose 会报"不是已知命令"。

Debian 用户只需把 URIs 的 ubuntu 改成 debian；官方另提醒：在 Debian testing 或 Kali 这类衍生版上，要把 Suites 里的变量表达式换成字面的版本代号（例如 trixie）。

Fedora / RHEL

# Fedora
sudo dnf config-manager addrepo --from-repofile https://download.docker.com/linux/fedora/docker-ce.repo
sudo dnf install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
sudo systemctl enable --now docker

# RHEL / Rocky（注意 config-manager 的参数写法与 Fedora 不同）
sudo dnf -y install dnf-plugins-core
sudo dnf config-manager --add-repo https://download.docker.com/linux/rhel/docker-ce.repo
sudo dnf install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
sudo systemctl enable --now docker

出现签名确认时，官方给的指纹是 060A 61C5 1B55 8A7F 742B 77AA C52F EB6B 621E 9F35。

02.4 便捷脚本：快，但官方明说不推荐生产用

curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh

脚本头部注释里列了它的问题，逐条都值得看：不推荐用于生产环境（"This script is not recommended for production environments."）、会不经确认就装依赖、不负责升级已有安装。它支持 Ubuntu/Debian、CentOS/Fedora/RHEL/Rocky、SLES 这些发行版，遇到已经停止维护（EOL，即官方不再发安全更新）的版本会直接拒绝。

02.5 静态二进制：连包管理器都没有的时候

官方提供打包好的压缩包，当前版本的文件名形如 docker-29.8.1.tgz。官方文档没写死文件名格式（写的是 /path/to/<FILE>.tar.gz），这个格式是从下载目录里核实的。完整步骤：

curl -fsSL https://download.docker.com/linux/static/stable/x86_64/docker-29.8.1.tgz -o docker.tgz
tar xzvf docker.tgz
sudo cp docker/* /usr/bin/
sudo dockerd &
sudo docker run hello-world

看到 sudo dockerd & 了吗——这条方式只是临时把后台手动拉起来，官方页面根本没给注册成系统服务的步骤。加上没有自动安全更新，官方的定位是一句很直白的话："mostly suitable for testing purposes"（主要适合测试）。

02.6 rootless 模式：不给后台 root 权限

前面 02.3 装完，你会发现自己老得敲 sudo（下面 02.8 讲怎么办）。那条路的代价是：谁进了 docker 组，谁就等于拿到了 root 权限——这是官方的原话（"The docker group grants root-level privileges to the user."）。

rootless 模式（"无 root 模式"）是官方的替代方案：让后台程序和容器都以普通用户身份运行，装的过程中也不用 root。官方说明它 "executes the Docker daemon and containers inside a user namespace"（在用户命名空间里跑），目的是 "to mitigate potential vulnerabilities in the daemon and the container runtime"。安装一条命令：

dockerd-rootless-setuptool.sh install

如果提示找不到这个脚本，装一下附加包：sudo apt-get install -y docker-ce-rootless-extras。没有包管理器的机器可以用 curl -fsSL https://get.docker.com/rootless | sh。

装完还要设两个环境变量（脚本会提示你）：

export PATH=/usr/bin:$PATH
export DOCKER_HOST=unix:///run/user/1000/docker.sock

前置条件里最容易漏的一个是：需要 newuidmap / newgidmap（通常在 uidmap 包里），以及 /etc/subuid、/etc/subgid 里给你的用户至少 65536 个从属 ID。

02.7 Docker Desktop 要不要钱？边界在这里

这是公司里用 Docker 时最现实的问题。官方许可页给的免费范围是四类，逐字如下：

• 小企业："fewer than 250 employees AND less than $10 million in annual revenue"——员工少于 250 人，并且年营收低于 1000 万美元（两个条件都要满足）；
• 个人使用；
• 教育用途；
• 非商业开源项目。

需要付费的情形：更大的组织里的专业使用、政府机构（注意政府实体不在免费之列）、以及超出免费范围的商业使用。覆盖它的订阅是 Docker Pro / Team / Business。

价格页面上写的是美元符号但没标币种，实际支付时以官方页面为准。Linux 服务器上装 Docker Engine 本身不涉及这套许可——收费针对的是 Docker Desktop 这个桌面产品。

02.8 装完怎么验：三条命令，分工不同

docker --version      # 只报客户端版本号
docker version        # Client 段 + Server 段；Server 报错 = 后台没起来
docker info           # 系统级信息：内核版本、容器数、镜像数、存储驱动、CPU/内存
docker run hello-world   # 官方的最小验证：拉一个几 KB 的镜像并跑一次

最后一条跑成功时，输出第一行是 Hello from Docker!，第二行是 This message shows that your installation appears to be working correctly.——这句话就是官方给"装好了吗"的答案。

"为什么我每条命令都要 sudo？"

原因官方写得很清楚：后台程序 "binds to a Unix socket, not a TCP port"（只在一个本地套接字上监听，不是网络端口），而且 "always runs as the root user"（永远以 root 身份跑）。所以普通用户默认没资格跟它说话。官方的解法是把你加进 docker 组：

sudo groupadd docker
sudo usermod -aG docker $USER
newgrp docker          # 让当前终端立刻生效；或者注销重登
docker run hello-world   # 不再需要 sudo 了

如果你之前一直用 sudo 跑命令，之后可能会撞上 ~/.docker/ 目录的权限错误，官方给的修法是：

sudo chown "$USER":"$USER" /home/"$USER"/.docker -R
sudo chmod g+rwx "$HOME/.docker" -R

02.9 不用 Docker Desktop 的几条替代路（Mac 用户尤其值得看）

Docker Desktop 有许可限制、也比较吃资源，Mac 上很多人会换别的。这些工具的共同思路是：照样提供一台 Linux 虚拟机和兼容的 docker 命令，只是不带那个图形界面。

装错了会怎样：两个真实的坑

03先跑通：把别人的镜像跑起来

在打包自己的项目之前，先拿现成的镜像练手——这一步不需要你写任何东西，只需要理解一条命令。这条命令你理解透了，后面 80% 的 Docker 操作都是它的变体。

03.1 把一条 docker run 拆开看

下面这条是本文后面会反复出现的"标准长命令"，先逐段拆一次：

docker run -d \
  --name my-web \
  -p 8080:80 \
  -v my-data:/app/data \
  -e NODE_ENV=production \
  --restart unless-stopped \
  nginx:alpine

03.2 端口方向：-p 8080:80 哪个在前？

这是新手第一个一定会背错的点。记住一个口诀就够了：像写信封一样，左边是"外面"，右边是"里面"。官方文档的原文是 "The first 8080 refers to the host port. The second 80 refers to the container port."——第一个是你电脑（宿主机）的端口，第二个是容器里的端口。

还有两个官方的补充规则值得一起记：不给 IP 时，Docker 默认在所有网卡上发布端口（"publishes the port on all interfaces (address 0.0.0.0) by default"）；只写一个端口（如 -p 80）时，Docker 会在主机上随机挑一个端口——用 docker port 容器名 能查出来是哪个。

安全上还有一句官方提示："Publishing container ports is insecure by default."——如果你只想让本机能访问，把 IP 写死：-p 127.0.0.1:8080:80。

03.3 "跑起来了，但浏览器打不开"——两个不同的原因

这是新手最经典的撞墙现场，而且有两个完全不同的原因，得分开查：

原因一：你没写 -p（外面这一侧不通）

官方原话："By default, containers are secure and isolated from outside network traffic – they do not expose any of its ports by default."——容器默认不与外界通网络，一个端口都不开。所以你想从浏览器访问，必须显式写 -p。这一点也解释了一个常见困惑：Dockerfile 里写了 EXPOSE 3000 并不等于端口开了（04.3 会让很多人吃惊）。

原因二：程序自己只监听了"内线"（容器里面这一侧不通）

这个更隐蔽，因为它看起来完全正常：容器在跑、端口也映射了，但就是连不上。根因是容器里那个程序只监听了 127.0.0.1——而 127.0.0.1 的意思是"只接受来自我自己这台机器的连接"。在容器里，"我自己"就是那个容器，Docker 转发进来的流量对它来说是"外来者"，直接被拒。

官方文档里最直接的一句出现在 Node.js 指南（讲调试端口时顺带说破）："Using 0.0.0.0 rather than localhost is necessary so the debugger is reachable from outside the container."——要用 0.0.0.0 而不是 localhost，才能从容器外面连进来。Flask 官方文档的说法是加 --host=0.0.0.0 后 "tells your operating system to listen on all public IPs"。

docker exec -it 容器名 ss -tlnp        # 列出容器里正在监听的端口和监听地址
docker exec -it 容器名 curl -s localhost:80   # 容器内自测：通 → 问题在映射，不通 → 问题在程序
docker port 容器名                    # 看主机端口到底映射到哪

03.4 日常看护：五条命令覆盖 90% 的情况

docker ps                 # 现在活着的容器
docker ps -a              # 包括已经退出的——排错第一步永远是它
docker logs -f my-web     # 跟着看日志（-f 表示持续输出）
docker stop my-web       # 优雅停机（先发 SIGTERM，默认等 10 秒再强杀）
docker rm my-web         # 删掉已停止的容器

三个容易忽略的细节：docker ps 默认只看运行中的，所以"我的容器不见了"的正确动作是 docker ps -a；docker logs 支持 --tail 100（只看最后 100 行）和 --since 42m（只看最近 42 分钟）；docker stop 的超时对 Linux 容器默认 10 秒、Windows 容器 30 秒。

03.5 一个具体例子：跑一个网页服务器，然后进去看看

把前面学的一次串起来，从零开始跑一个 nginx（一个网页服务器软件）：

# 1. 跑起来：本机 8080 → 容器 80，后台，起名叫 web
docker run -d --name web -p 8080:80 nginx:alpine

# 2. 确认它在跑
docker ps
# CONTAINER ID   IMAGE          STATUS         PORTS                    NAMES
# 3f2a1b9c8d7e   nginx:alpine   Up 3 seconds   0.0.0.0:8080->80/tcp    web

# 3. 浏览器打开 http://localhost:8080 —— 应该看到 nginx 欢迎页

# 4. 钻进容器里看看（-i 保持输入 -t 分配终端，合起来就是 -it）
docker exec -it web sh
# 现在你在容器内部了：
#   ls /usr/share/nginx/html     看到那个欢迎页文件
#   cat /etc/os-release          看到这是一个 Alpine Linux
#   exit                         退出（容器不会停）

# 5. 收工
docker stop web && docker rm web

第 4 步里有一个细节值得体会：exec 用的是 sh 而不是 bash。因为 Alpine 这种迷你 Linux 里根本没有 bash。官方文档的所有示例也都写 sh——这是很实用的一条经验：进不去容器时，先怀疑你要的 shell 不存在。

另外注意第 4 步和第 5 步的区别：exec 是在正在运行的容器里再开一个进程，退出它不影响容器；而 stop 是让容器停下来。

04打包自己的项目：Dockerfile 逐行拆

到这里正式进入本文的主线：把自己的项目做成一个能送人的镜像。要做的事只有两件——写一份说明书，然后让 Docker 照着它造。

04.1 说明书就是 Dockerfile，造的动作叫 build

这份说明书叫 Dockerfile（一个名字就叫这个的文件，没有后缀）。它是一份文本文件，每行一条指令，说的是："从哪个底子开始、把哪些文件放进去、装什么、启动时跑什么。"

让 Docker 照着它造出镜像的动作叫 构建（build）：

docker build -t myapp:1.0 .

这条命令里有三个东西必须看懂，否则后面会一直犯错：

04.2 不想从零写？docker init 能生成一份草稿

Docker 提供了一条生成说明书的命令：docker init，官方描述是 "Creates Docker-related starter files for your project"。它支持 ASP.NET Core、Go、Java、Node、PHP with Apache、Python、Rust，以及一个通用的 Other。生成四个文件：.dockerignore、Dockerfile、compose.yaml、README.Docker.md。

cd 你的项目
docker init        # 它会问你项目用什么语言、监听哪个端口

它是很好的起点，但生成的草稿不等于理解的替代品——下面还是把每一行拆开讲，因为调错的时候你得知道该改哪。

04.3 最小例子：一份 Node.js 的 Dockerfile，逐行讲

假设你的项目长这样（一个简单的 Node 服务）：

myapp/
├── package.json
├── package-lock.json
├── server.js
└── .dockerignore

在这份目录里新建一个名叫 Dockerfile 的文件，内容如下——这份可以直接抄，改掉端口和启动命令就行：

FROM node:24-alpine

WORKDIR /app

COPY package.json package-lock.json ./
RUN npm ci --omit=dev

COPY . .

EXPOSE 3000
CMD ["node", "server.js"]

再建一个 .dockerignore（下面 04.5 会给完整内容）。然后：

docker build -t myapp:1.0 .
docker run -d --name myapp -p 3000:3000 myapp:1.0

逐行解释这份说明书——每一行对应镜像里的一层，理解这点是理解缓存的前提：

CMD 和 ENTRYPOINT 到底差在哪

这是新手最容易混的一对，值得单独说清。区别不在"谁先谁后"，而在用户给的参数是覆盖还是追加：

两个配套的坑也要知道：① 用 shell 形式写的 ENTRYPOINT 会忽略 CMD 和用户给的参数（官方原话："ignores any CMD or docker run command line arguments"），所以想要"参数能追加"就必须用中括号那种 ["命令","参数"] 的写法（这叫 exec 形式）。② 想让 CMD 给 ENTRYPOINT 提供默认参数，两个都必须用中括号形式，官方原话是 "both the CMD and ENTRYPOINT instructions should be specified in the exec form"。

还有一个格式细节：中括号形式里必须用双引号，"you must use double-quotes around words, not single-quotes"——写成单引号不会报错，但参数会带上引号本身传进去，非常难查。

04.4 第二个例子：Python 项目

换成 Python，结构大同小异，关键是"先把依赖装上、再拷代码"这个顺序：

FROM python:3.14-slim

WORKDIR /app

COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY . .

EXPOSE 8000
CMD ["python", "-m", "uvicorn", "app:app", "--host=0.0.0.0", "--port=8000"]

注意倒数第二行的 --host=0.0.0.0——这就是 03.3 讲的"必须监听 0.0.0.0 才能从外面连进来"。官方 Python 指南里的启动命令同样带着这个参数。

这里用的 python:3.14-slim 是"精简版"标签。为什么不用默认标签，看下面这张表就明白了。

04.5 镜像为什么动辄几百 MB（以及怎么瘦下来）

数字来自 Docker Hub 的官方仓库页与它的接口（hub.docker.com/_/python），抓取日期 2026-09-16，都是压缩后的体积；解压到磁盘上会比这更大。为什么 python 默认标签这么胖？官方镜像页给了解释：它基于 buildpack-deps，而这个底子 "by design, has a large number of extremely common Debian packages"——故意塞了一堆常用包，目的是让基于它的镜像少装东西、整体更省。官方也承认："This is an unfortunate side-effect of using the buildpack-deps image in the non-slim variants."

04.6 .dockerignore：一个容易被跳过、但必须写的文件

它和 .gitignore 长得很像，作用不同：它决定哪些文件不进入构建上下文（也就是不发给构建器）。官方的理由是 "This helps avoid sending unwanted files and directories to the builder"，从而加快构建。

一份可以直接用的 .dockerignore（内容合并自官方 Node 与 Python 两份指南）：

node_modules/
dist/
.env
.env.*
.git
.gitignore
.DS_Store
npm-debug.log*
coverage/
db/
**/__pycache__
**/.venv
**/Dockerfile*
**/compose.y*ml
LICENSE
README.md

三条规则要知道：它在上下文根目录被查找；以 ! 开头表示"例外，要包含"；最后一条匹配的规则说了算（"the last line of the .dockerignore that matches a particular file determines whether it's included or excluded"）。

04.7 为什么"我改了代码，镜像却没变"

先讲机制，因为它同时解释了"构建很慢"和"改了没生效"两件事。

Dockerfile 里每一行指令，都会在镜像里产生一层（官方原话："Each instruction in this Dockerfile translates to a layer in your final image."）。Docker 会缓存这些层，规则是：某一层变了，它之后的所有层都要重做——"If a layer changes, all other layers that come after it are also affected."

把这句话套到我们的顺序上，就明白了为什么依赖安装要单独一行写在前面：

COPY . .
RUN npm ci

COPY package.json package-lock.json ./
RUN npm ci
COPY . .

还有一条会让人困惑的官方细节：改文件的修改时间不会让缓存失效——"The modification time of a file (mtime) is not taken into account"，它看的是文件内容的校验和。而 RUN 那条更特别："The cache for RUN instructions isn't invalidated automatically between builds"——它只看命令字符串是否一模一样。所以 RUN apt-get update 这种写法会一直用旧缓存，你以为更新了其实没有。

真到了需要彻底重来的时候：docker build --no-cache -t myapp:2.0 .。

04.8 多阶段构建：把"编译用的东西"留在门外

前端项目和编译型语言有一个共同问题：要造出成品，需要一整套工具链（编译器、构建工具、开发依赖）；但跑起来的时候，这些工具一个都不需要。多阶段构建（multi-stage build）就是官方给的解法：在同一份 Dockerfile 里写多个 FROM，每个开一个新阶段，最后只把成品从前面阶段"拎"过去。

官方说法是它能让最终镜像里 "None of the build tools required to build the application are included in the resulting image"——构建用的工具一个都不会留在成品镜像里。

# ---- 第一阶段：builder —— 装全量依赖并编译 ----
FROM node:24-alpine AS builder
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci
COPY . .
RUN npm run build

# ---- 第二阶段：deps —— 只装生产依赖 ----
FROM node:24-alpine AS deps
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci --omit=dev

# ---- 第三阶段：runner —— 只带产物和运行时依赖 ----
FROM node:24-alpine AS runner
ENV NODE_ENV=production
ENV PATH=/app/node_modules/.bin:$PATH
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY --from=builder /app/dist ./dist
COPY package.json ./
EXPOSE 3000
CMD ["node", "dist/index.js"]

三段的关键在最后那三行 COPY --from=：从别的阶段（或别的镜像）里把文件搬过来。所以 runner 这一阶段里既没有编译工具，也没有开发依赖，只有"能跑起来的最小集合"。

给阶段起名字（AS builder）不只是为了好读，官方说它还带来一个好处：即使以后调整了指令顺序，"the COPY doesn't break"——用名字引用比用序号引用稳。

另一个实用点：可以用 --target 只构建到某个阶段，官方 Node 指南里的例子是这样的：

docker build --target builder -t myapp:dev .     # 只造到 builder，方便调试
docker build -t myapp:prod .                      # 造完整的（默认最后一个阶段）
docker image ls                                   # 自己量：两个镜像分别多大

04.9 到这里你手上有什么

走到这一步，你有了一个存在本机、有名字、有标签的镜像。用 docker images 能看到它：

docker images
# REPOSITORY   TAG       IMAGE ID       CREATED          SIZE
# myapp        1.0       a1b2c3d4e5f6   5 seconds ago    62MB

但注意：这个镜像现在只有你自己看得见。它躺在你本机，别人拉不到、也拿不到。怎么送出去是第 06 节的事。中间还有一节——先把它跑起来跑对。

05把自己的镜像跑起来：数据、配置，和"一条命令起一整套"

05.1 最短的一步：跑你自己的镜像

docker run -d --name myapp -p 3000:3000 myapp:1.0
docker logs -f myapp

和 03 跑 nginx 完全一样，只是镜像名换成了你自己造的。如果你看到容器起来又立刻退出（docker ps -a 里状态是 Exited (0)），大概率是说明书最后那行 CMD 写的命令跑完就返回了——这是最常见的"启动即退出"原因，具体见 09 排错表。

05.2 数据会丢：卷（volume）解决什么问题

官方对这件事有一句反复出现的话："When a container is destroyed, the writable layer is destroyed with it."——容器被销毁时，它那一层可写的数据一起销毁。数据库跑在容器里、用户表存在容器里，docker rm 一下就全没了。

解法是把数据放到容器外面。Docker 有两种挂法，名字和用途都不一样：

一条经验法则：生产用卷，开发用绑定挂载。开发时把源码挂进去，改文件不用重新造镜像；跑数据库时用卷，容器删了数据还在。

回到那条长命令：-v my-data:/app/data 里的 my-data 只有名字、没有斜杠，所以它是具名卷，数据由 Docker 管理。

05.3 Compose：把一堆 docker run 收进一个文件

一个真实项目往往不止一个容器：一个 Web 服务 + 一个数据库。用 docker run 起它们，你得记住两条长命令、记住启动顺序、还得手工建一个网络让它们能互相找到。Compose 就是干这个的。

官方定义："Docker Compose is a tool for defining and running multi-container applications."——定义并运行多容器应用的工具。它把整套东西写进一个 YAML 文件（一种缩进表示层级的配置格式），然后一条命令起全套。

文件名有讲究：官方现在推荐 compose.yaml（"The default path for a Compose file is compose.yaml (preferred) or compose.yml"），同时也兼容老名字 docker-compose.yml。另外一件常被旧教程带偏的事：文件开头的 version: 字段已经废弃——官方把它标为 "obsolete"，写了会收到警告，不写完全没问题。

# compose.yaml —— 不要写 version:
name: myapp

services:
  web:
    build: .                       # 用当前目录的 Dockerfile 现场构建
    image: myapp:1.0               # 构建出来的镜像叫什么名字
    ports:
      - "8080:3000"                # 主机 8080 → 容器 3000
    environment:
      DB_HOST: db                  # 直接用服务名当主机名，Compose 内置了 DNS
      DB_PORT: "5432"
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}   # 从同目录 .env 文件读
    depends_on:
      db:
        condition: service_healthy # 等数据库真的能用了再启动
    volumes:
      - ./src:/app/src             # 开发期把源码挂进去，改完不用重造镜像
    restart: unless-stopped

  db:
    image: postgres:17-alpine
    environment:
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
    volumes:
      - db-data:/var/lib/postgresql/data   # 具名卷：数据库的数据必须活过容器
    healthcheck:                   # 健康检查：每隔几秒跑一条命令，确认它真的能用了
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 5s
      timeout: 3s
      retries: 5
      start_period: 10s

volumes:
  db-data:

配套命令，这五条覆盖日常：

docker compose up -d            # 后台起整套（-d 不加的话，你按 Ctrl+C 会全停）
docker compose up -d --build    # 改了 Dockerfile 后重建再起
docker compose ps               # 看这一套的状态
docker compose logs -f web      # 盯着某个服务的日志
docker compose down             # 收摊：删容器和网络，保留具名卷
docker compose down -v          # 连卷一起删（数据也没了，慎用）

两个容易踩的点：up 不加 -d 时，官方说 "When the command exits, all containers are stopped"——你退出它就全停；down 默认不删具名卷（官方："Networks and volumes defined as external are never removed"，具名卷会留着），想删得加 -v。这条设计救过很多人的数据库。

还有一个 Compose 特有的便利：服务之间可以直接用服务名互相访问。上面 web 里写 DB_HOST: db 就是这个意思——Compose 建了一个网络，每个服务用自己的名字在里面注册，官方建议 "you should always reference services by name, not IP address"。

06分享给别人：四条路，各有各的适用场合

到这一步该问一个关键问题了：你要把它给谁、以什么方式给？答案不同，做法完全不同。先看这张总表，再往下看细节。

06.1 先看懂镜像名：为什么它长得像网址

推送之前必须先看懂镜像名的结构，因为它决定了"推到哪去"。官方给的格式是 [HOST[:PORT_NUMBER]/]PATH[:TAG]：

官方给的例子最能说明问题：nginx 其实等价于 docker.io/library/nginx:latest；而 ghcr.io/dockersamples/example-voting-app-vote:pr-311 则指明了"去 ghcr.io 这个仓库、找 dockersamples 这个命名空间"。

06.2 A 路：推到镜像仓库（8 个渠道逐个说）

推之前必须做的一件事是登录。官方原话："Before you're able to push an image to a repository, you will need to be authenticated."——没登录就推，会得到 requested access to the resource is denied。登录的通用写法：

echo "$DOCKERHUB_TOKEN" | docker login -u 你的用户名 --password-stdin

为什么用 --password-stdin 这种绕一圈的写法？官方解释："Using STDIN prevents the password from ending up in the shell's history, or log-files."——避免密码出现在你的命令历史和日志里。直接用 -p 密码 会留在 ~/.zsh_history 里。

① Docker Hub：默认的那个

echo "$DOCKERHUB_TOKEN" | docker login -u 你的用户名 --password-stdin
docker tag myapp:1.0 你的用户名/myapp:1.0
docker push 你的用户名/myapp:1.0
docker pull 你的用户名/myapp:1.0

建仓库的两条规则值得提前知道：名字只能是小写字母、数字、连字符和下划线，长度 2–255；而且建好之后不能改名（"You can't rename a Docker Hub repository once it's created."）。官方还建议：拿不准可见性时选私有。

② GitHub Container Registry（ghcr.io）：和代码放一起

export CR_PAT=你的令牌
echo $CR_PAT | docker login ghcr.io -u 你的GitHub用户名 --password-stdin
docker tag myapp:1.0 ghcr.io/你的用户名/myapp:1.0
docker push ghcr.io/你的用户名/myapp:1.0

认证要用个人访问令牌（PAT，一串代替密码的授权字符串）：官方明确 "GitHub Packages only supports authentication using a personal access token (classic)"，需要 write:packages 权限（拉取则要 read:packages）。一个小坑是：在网页上勾 write:packages 会顺带勾上一个范围很大的 repo 权限，官方为此专门给了一个链接 https://github.com/settings/tokens/new?scopes=write:packages。另外首次推送的包默认是私有的。

费用方面：官方说 GitHub Packages 公开包免费，而且容器这部分目前更宽松——"Container image storage and bandwidth for the Container registry is currently free."（变更前会提前至少一个月通知）。

③④ 云厂商的三个：ECR / Artifact Registry / ACR

选哪个基本是"你已经在用哪家云"决定的：代码在 GitHub 上就顺手用 ghcr.io，云主机在 AWS 上就用 ECR，公司有 GCP 就用 Artifact Registry。没有云端偏好、只是想公开分享，Docker Hub 是最省事的。

⑤ Quay.io

Red Hat 家的仓库，官方博客的说法是 "Quay offers free accounts for public repositories, and paid plans for private repositories"——公开仓库免费、私有仓库要付费。它在国内用的人不算多，选它的典型理由是"公司本来就买 Red Hat 的东西"。本站在核对时 quay.io 的定价页打不开，所以具体限额这里不给数字，请以你看到的官网为准。

⑥ 自建 registry：一条命令起一个自己的仓库

不想把镜像放到别人服务器上时（内网、客户现场、公司自管），可以自己起一个：

# 起一个本地仓库服务（带上持久化目录）
docker run -d -p 5000:5000 --restart=always --name registry \
  -v /mnt/registry:/var/lib/registry \
  registry:3

# 推给它（注意镜像名里要带上地址和端口）
docker tag myapp:1.0 localhost:5000/myapp:1.0
docker push localhost:5000/myapp:1.0
docker pull localhost:5000/myapp:1.0

需要更完整的能力（权限、审计、图形界面）时，业界常用 Harbor——官方自述是一个"open source registry that secures artifacts with policies and role-based access control"（用策略和基于角色的访问控制保护制品的开源仓库），是 CNCF（管理云原生开源项目的基金会）的毕业项目。它的最低要求是 2 CPU / 4 GB 内存 / 40 GB 磁盘，推荐 4 CPU / 8 GB / 160 GB。

推之前的三个自查

RUN --mount=type=secret,id=aws \
    AWS_SHARED_CREDENTIALS_FILE=/run/secrets/aws \
    aws s3 cp ...

# 构建时这样传：
docker build --secret id=aws,src=$HOME/.aws/credentials -t myapp:1.0 .

06.3 B 路：打成一个 tar 文件，直接发给他

对方没有账号、机器不能上外网、或者只是临时给一次——用这条路最干净。官方对 docker save 的说明是它 "Save one or more images to a tar archive"，而且内容里 "Contains all parent layers, and all tags + versions"——包含全部底层和标签。

# 导出方（你）
docker save -o myapp.tar myapp:1.0

# 文件太大就顺手压缩（load 能直接读 gzip 压缩过的）
docker save myapp:1.0 | gzip > myapp_1.0.tar.gz

# 接收方（他）
docker load < myapp.tar
docker load --input myapp.tar
docker load < myapp_1.0.tar.gz

# 载入之后照常跑
docker run -d -p 8080:3000 --name myapp myapp:1.0

官方说明 docker load 能读 "even if compressed with gzip, bzip2, xz or zstd"（这四种都是常见的压缩格式），而且 "restores both images and tags"——连标签一起恢复，所以对方载入后镜像名和你这边一模一样。

顺便说清两个容易混的命令

你在搜索时一定会看到 docker export 和 docker import，它们不是发给别人的正确工具：

• docker export：官方描述是 "Export a container's filesystem as a tar archive"——导出的是"某个容器"的文件系统，不是镜像。而且官方明确 "The docker export command doesn't export the contents of volumes associated with the container."（不含卷的内容）。
• docker import：把这样的 tar 包变回一个文件系统镜像（"Import the contents from a tarball to create a filesystem image"）。
• 诚实提示：网上常说"export/import 会丢历史、丢元数据"。我查了官方四个页面，没有找到这句原话——官方页面之间甚至互不引用。所以这里只说有依据的部分：save/load 明说了"含全部父层与标签"，export 明说了"导出的是容器文件系统、不含卷"。要给镜像发人，用 save/load。

06.4 C 路：把源码和说明书一起给他

这是四条路里对新手最友好、也最透明的一条：你把项目目录打包发过去，他一条命令既构建又运行。对方能看到全部内容，也能自己改。

你要发的就是这几样：

myapp/
├── Dockerfile          # 说明书
├── .dockerignore       # 别把 node_modules、.env 发过去
├── compose.yaml        # 一条命令起全套
└── （你的项目源码）

他那边只需要两条命令：

docker compose up --build -d
# 或者不用 compose：
docker build -t myapp:1.0 .
docker run -d -p 8080:3000 myapp:1.0

compose.yaml 里的 build: . 就是"用这个目录的 Dockerfile 现场构建"的意思；官方说明 build 字段 "specifies the build configuration for creating a container image from source"，而且 image 字段在有 build 时可以省略。

06.5 D 路：跨芯片——"我这跑得好好的，他那报 exec format error"

这是分享环节最容易被忽略、发作起来最懵的一个坑。场景：你在 M 系列芯片的 Mac 上构建，镜像里的程序是 arm64 架构的；对方的电脑或服务器是 Intel/AMD 的 x86_64（也叫 amd64）。他那边跑起来直接报错，甚至报的是一串看不懂的 exec format error。

为什么不能凑合跑？官方把根因说得很直接："the code that's running inside the container must be compatible with the host's architecture"，举的例子就是 "you can't run a linux/amd64 container on an arm64 host (without using emulation)"——架构必须对得上，除非用模拟。（架构就是 CPU 的指令集类型：Apple 芯片是 arm64，多数 Intel/AMD 电脑和云服务器是 amd64。）

解法是构建出"多架构镜像"，让同一个名字下面同时装着两个版本，对方拉的时候自动挑对的那个：

# 只给对方那一种架构构建（省时间）
docker buildx build --platform linux/amd64 -t 你的用户名/myapp:1.0 --push .

# 两种架构一起构建，推成同一个标签
docker buildx build --platform linux/amd64,linux/arm64 \
  -t 你的用户名/myapp:1.0 --push .

# 想先做一个能同时构建多平台的构建器：
docker buildx create --name container-builder --driver docker-container --bootstrap --use

三个关键细节：

• 多架构必须 --push（或推到仓库），不能只留在本地。官方解释是 "Multi-platform images require an image store that supports manifest lists"——多架构镜像需要一个支持"多架构清单"的本地存储。这也意味着这条路和 06.2 的推送是绑在一起的；对方仍然通过 docker pull 拿。
• 靠模拟跑另一种架构会慢很多。官方原话 "Emulation with QEMU can be much slower than native builds"。好消息是 Docker Desktop 默认支持，"BuildKit automatically detects the architectures that are available for emulation"，而且 "Using emulation requires no changes to your Dockerfile"——你的 Dockerfile 一个字都不用改。
• 怎么确认自己需要它：让对方敲 uname -m，跟你本机的输出比。不一样就得走这条路。

06.6 最后怎么选：一句话

回到本节开头那张表：给很多人长期用 → A；给一个人只给一次、他那不能上外网 → B；对方要改代码或要看清楚里面是什么 → C；芯片不一样 → 在任何一条上加 D。A 路还有个附带的判断：代码在 GitHub 上就用 ghcr.io，云主机在哪家就用那家的仓库，纯公开分享用 Docker Hub。

07对方收到之后：从他那边看完整流程

这一节换个视角：假设镜像已经送到了，对方手上该敲什么。把这一段直接发给对方，通常比你在聊天里解释半小时有用。

07.1 前提：他得先有 Docker

镜像再小，对方机器上也得有 Docker 才能跑。这一步没法省——按 02 让他装（Mac/Windows 装 Docker Desktop，Linux 服务器装 Engine）。装完让他跑 docker run hello-world 验证，看到 "Hello from Docker!" 就说明环境好了。

07.2 从仓库拉：三条命令

# 公开仓库：直接拉
docker pull 你的用户名/myapp:1.0

# 私有仓库：先登录（把仓库地址也带上）
echo "$TOKEN" | docker login ghcr.io -u 用户名 --password-stdin
docker pull ghcr.io/你的用户名/myapp:1.0

# 跑起来
docker run -d --name myapp -p 8080:3000 \
  -e DB_HOST=host.docker.internal \
  你的用户名/myapp:1.0

私有仓库最常见的报错是 requested access to the resource is denied——十有八九是没登录，或者镜像名里的用户名写错了。让对方先 docker login 再试。

07.3 从 tar 文件：两条命令

docker load < myapp_1.0.tar.gz
docker run -d --name myapp -p 8080:3000 myapp:1.0

07.4 从源码：一条命令

docker compose up --build -d

07.5 跑起来之后，让对方确认这三件事

07.6 一个完整的交付话术（可以直接复制给人）

08十个必踩的坑（按踩到概率排序）

09排错对照表：照着报错找

10一页纸速查

装完到分享：最短路径

# 1. 验证装好了
docker run hello-world

# 2. 对着自己的项目写一份 Dockerfile（见 04.3），然后造镜像
docker build -t myapp:1.0 .

# 3. 本地跑起来确认
docker run -d --name myapp -p 8080:3000 myapp:1.0
docker logs -f myapp

# 4. 推到仓库分享
docker login -u 你的用户名
docker tag myapp:1.0 你的用户名/myapp:1.0
docker push 你的用户名/myapp:1.0

# 5. 对方那边
docker pull 你的用户名/myapp:1.0
docker run -d -p 8080:3000 你的用户名/myapp:1.0

日常命令速查（附"什么时候用"）

11名词对照表（回头查用）

12常见问题

99一句话总结

98参考来源与证据边界

一手来源（本次逐页核对）

• docs.docker.com/engine/ — Docker Engine 的定义与三部分组成（daemon / API / CLI）
• docs.docker.com/get-started/docker-overview/ — 镜像与容器的官方定义（"read-only template"）、客户端-服务端架构、容器删除后数据消失
• docs.docker.com/.../what-is-a-container/ — 容器共用内核、容器 vs 虚拟机
• docs.docker.com/.../what-is-an-image/ — 镜像不可变、镜像由层组成
• docs.docker.com/desktop/release-notes/ — Docker Desktop 4.91.0（2026-09-14）及其内含组件版本
• docs.docker.com/engine/release-notes/29/ — Docker Engine 29.8.1（2026-09-15）
• docs.docker.com/desktop/setup/install/mac-install/ — macOS 安装要求
• docs.docker.com/desktop/setup/install/windows-install/ — Windows 版本门槛、WSL 要求、安装器参数、Windows 容器限制
• docs.docker.com/engine/install/ubuntu/ — Ubuntu apt 仓库的 deb822 写法、需卸载的 unofficial packages
• docs.docker.com/engine/install/debian/ / rhel / fedora — 各发行版命令与 GPG 指纹
• docs.docker.com/engine/install/binaries/ — 静态二进制步骤、macOS 只提供 client
• docs.docker.com/engine/security/rootless/ — rootless 模式的机制、前置与命令
• docs.docker.com/engine/install/linux-postinstall/ — docker 用户组、权限修法、"docker 组等于 root"警告
• docs.docker.com/subscription/desktop-license/ — Docker Desktop 免费范围（250 人 / 1000 万美元）
• docker.com/pricing — 各档价格
• docs.docker.com/reference/cli/docker/container/run/ — run 全部参数语义、端口方向、detach 的退出行为
• docs.docker.com/reference/cli/docker/version/ — docker version 与 docker --version 的分工
• docs.docker.com/reference/dockerfile/ — FROM / WORKDIR / COPY / RUN / EXPOSE / CMD / ENTRYPOINT 的官方定义
• docs.docker.com/reference/cli/docker/init/ — docker init 的支持模板、生成的四个文件、覆盖警告
• docs.docker.com/build/building/context/ — 构建上下文与 .dockerignore 的机制
• docs.docker.com/build/building/multi-stage/ — 多阶段构建
• docs.docker.com/build/cache/ 与 cache/invalidation — 层缓存与失效规则
• docs.docker.com/build/building/multi-platform/ — 多架构构建、QEMU 模拟、必须 push 的原因
• docs.docker.com/build/builders/ — 默认构建器与 BuildKit
• docs.docker.com/engine/storage/volumes/ 与 bind-mounts — 卷与绑定挂载
• docs.docker.com/engine/network/port-publishing/ — 端口发布的默认行为与安全提示
• docs.docker.com/compose/ 与 compose/how-tos/networking/ — Compose 定义、服务名互相访问
• docs.docker.com/reference/compose-file/version-and-name/ — version 字段已废弃
• docs.docker.com/.../build-tag-and-publish-an-image/ — 镜像名结构、推送前必须认证
• save / load / export / import — 四条命令的官方描述
• docs.docker.com/docker-hub/download-rate-limit/ 与 usage/pulls — Docker Hub 拉取限流的数字与 429 行为
• docs.docker.com/build/building/secrets/ — 为什么构建参数会留在镜像里、secret 挂载的做法
• docs.docker.com/engine/daemon/troubleshoot/ — daemon 连接问题排查（DOCKER_HOST 等）
• docs.docker.com/guides/nodejs/ — 0.0.0.0 监听、官方 .dockerignore、官方 Node 三阶段写法
• docs.docker.com/guides/python/ — 官方 Python 指南（uvicorn、slim/dhi 镜像、glob 式 .dockerignore）
• hub.docker.com/_/python 与 _/node、_/alpine、_/ubuntu — 各镜像体积与标签说明（2026-09-16 抓取）
• docs.github.com/.../working-with-the-container-registry — ghcr.io 认证方式与 scope
• docs.aws.amazon.com/.../getting-started-cli 与 ECR Public 认证 — ECR 登录与推送
• cloud.google.com/artifact-registry/pricing 与 推送指南 — Artifact Registry 免费额度与镜像名格式
• learn.microsoft.com/.../container-registry-skus — ACR 三档与价格示例
• distribution.github.io/distribution/about/deploying/ — 自建 registry 的部署与"仅测试用"警告
• goharbor.io — Harbor 的定位与安装前提
• flask.palletsprojects.com/.../externally-visible-server — --host=0.0.0.0 的作用（用于补 Docker 文档的空白）
• get.docker.com 与 github.com/docker/docker-install — 便捷脚本的适用警告
• formulae.brew.sh/cask/docker-desktop — Homebrew cask 的 macOS 版本要求（明确区别于 Docker 官方文档）
• github.com/microsoft/winget-pkgs/.../Docker.DockerDesktop — winget 包标识符与版本（非 Docker 官方文档）
• github.com/abiosoft/colima、podman-desktop.io、orbstack.dev、github.com/lima-vm/lima — 四个替代品各自的官方说明

本文自己做的核对

除官方文档外，本次还从 download.docker.com 的仓库与静态二进制目录直接确认了当前版本号（docker-ce_29.8.1-1~ubuntu.24.04~noble_amd64.deb、docker-29.8.1.tgz），从 Docker Hub 的镜像接口读取了各镜像标签的实际体积（上表所有 MB 数字），并从 packages.ubuntu.com 核对了 Ubuntu 自带 docker.io 的版本（24.04 上是 29.1.3）。