Docker 装完就跑不起来？Windows 与 Linux 的部署流程我拆开讲
很多人第一次装 Docker，是在自己的开发机上：Windows 里下个 Docker Desktop，点几下就起来了，跑个 hello-world 也挺顺。等到要把同一套东西搬到 Linux 服务器上，才发现镜像拉不下来、容器起不来、端口映射没反应。这两条路的坑完全不一样，混着讲只会越看越乱。我下面把 Windows 和 Linux 分开说，每一步卡在哪里、代价是什么，都尽量讲清楚。
Windows 上先想清楚用 WSL2 还是 Hyper-V
Docker Desktop 在 Windows 上有两种后端，选错了后面全是麻烦。
WSL2 后端是现在的默认推荐，启动快、和 Windows 文件系统互通方便，缺点是它本质上跑了一个轻量虚拟机，默认会吃掉一部分内存。如果你机器只有 8GB 内存，再开几个容器，编译的时候很容易卡到鼠标都动不了。
Hyper-V 后端隔离更彻底，适合需要和宿主机网络严格分开的场景，但它要求 Windows 专业版及以上，家庭版装不了。这一步很多人是装到一半才发现，白折腾半天。
我一般会先问一句：这台机器内存多大？16GB 以下就老老实实 WSL2，并且去 .wslconfig 里把内存上限压到 4GB 左右；16GB 以上、又需要跑多个隔离环境，再考虑 Hyper-V。
装完之后第一件事不是急着跑项目，而是把镜像加速配好。国内直连 Docker Hub 拉一个几百 MB 的镜像，等十几分钟是常事。在 Docker Desktop 的设置里加上镜像源，同样的镜像通常一两分钟就能下来。
Linux 上的部署流程，顺序比命令重要
Linux 服务器上装 Docker，最省事的做法是用官方脚本，但脚本默认装的是最新版，有些老内核跑不动，装完 daemon 起不来。所以顺序上我一般是这样：
- 先看内核版本，uname -r 低于 3.10 的老系统，Docker 新版基本不认，得考虑升级系统或者用旧版本。
- 再确认存储驱动。overlay2 是现在的默认，性能和兼容性都稳；如果文件系统是 btrfs，可以直接用 btrfs 驱动，快照和子卷管理方便，但对运维熟悉度要求高一些。
- 最后才是装包、起服务、加用户组。
加用户组这一步看着小，实际很关键。不把当前用户加进 docker 组，每次敲命令都得带 sudo，写脚本的时候尤其烦。加完要重新登录一次 shell 才生效，很多人加完立刻试，发现还是要 sudo，以为没成功。
镜像源同样要配。改 /etc/docker/daemon.json，把 registry-mirrors 写进去，然后重启 daemon。这一步不做，后面 pull 镜像的体验会差很多。
最容易翻车的其实是网络和端口
容器跑起来了，外面访问不到，十有八九是端口映射或者防火墙。
Windows 上因为 WSL2 有自己的网络栈，localhost 转发偶尔会抽风，重启 Docker Desktop 一般能恢复；Linux 上更常见的是宿主机防火墙没放行——比如你映射了 8080，但 iptables 或 firewalld 没开这个口，外面就是连不上。
另一个坑是容器之间互相访问。用默认的 bridge 网络，容器只能靠 IP 找对方，IP 每次重启还可能变。要稳定，就自己建一个自定义 bridge 网络，把相关容器都挂上去，容器名直接当主机名用，省掉一堆改配置的功夫。
如果服务要长期跑、又要对公网提供稳定访问，单机 Docker 到后面会越来越吃力：镜像更新、端口冲突、资源争抢，都得手动处理。这种情况我会倾向于把容器放到一台独立的物理服务器上，资源是独占的，不用和别的业务抢 CPU 和内存。像 德国裸机云 XII 这类配置，E5-2683v4*2 加 64G 内存，跑十来个中等规模的容器负载比较从容，月付 $159.00，对需要固定 IP、固定带宽的部署场景更省心。
回到具体选择上：本地开发验证阶段，Windows 用 Docker Desktop 加 WSL2 后端，内存压到 4GB 以内，够用；要上生产，优先选 Linux，内核 4.x 以上、存储驱动 overlay2，镜像源配好。端口映射和自定义网络这两件事，在写第一行 compose 文件之前就想清楚，能省掉后面大量的排查时间。