从拉镜像到开机自启：Docker 在 Windows 和 Linux 上的部署差异

第一次在 Windows 上把 Docker 跑起来的人，多数会经历同一个瞬间：命令敲下去，容器是起来了，可一访问映射端口就是连不上。换成 Linux 机器，同样的镜像、同样的 compose 文件，一次就通。差别不在命令本身，而在 Docker 到底跑在哪一层内核上。搞清楚这一点，后面装什么、挂什么、开什么端口，思路就顺了。

这篇按真实部署顺序走：先讲两边安装时真正要做的选择，再讲镜像拉不动怎么办，然后是数据卷和端口这两个最容易出问题的环节，最后落到服务器配置和开机自启。

Windows 上先决定用 WSL2 还是 Hyper-V，这一步影响后面所有事

Windows 装 Docker 有两条路。一条是装 Docker Desktop，底层挂 WSL2；另一条是在 Hyper-V 里跑一台 Linux 虚拟机自己装。两条路我都用过，现在基本只推 WSL2。

WSL2 的好处是文件系统打通，你在 Windows 里写的代码可以直接挂进容器，改完刷新就生效。代价是跨文件系统的 IO 会慢，尤其是把项目放在 /mnt/c 下再挂载进容器，编译类任务能明显感觉到卡。

我的做法是把代码放在 WSL 自己的文件系统里，比如 ~/projects，Windows 侧用 VS Code 的远程连接去编辑。这样挂载路径短，读写也快。

Hyper-V 那条路适合公司内网有强制策略、不允许开 WSL 的场景，但网络配置要自己搭桥接，端口映射经常要手动调，新手不建议从这里起步。

镜像拉不下来时，先换源再谈别的

国内直连 Docker Hub 拉镜像，多数时候会卡在下载中途。处理顺序是这样的：

• 先配镜像加速地址，改 /etc/docker/daemon.json，加上 registry-mirrors 字段后重启 docker 服务；
• 加速地址也不稳定时，直接找现成的镜像仓库把镜像 push 过去，再从那边拉。

Windows 侧改的是 Docker Desktop 设置里的 Docker Engine 配置，改完点应用重启，效果和 Linux 上改 json 一样。

拉一个 nginx:alpine 大概几十 MB，如果几分钟还没动，基本可以判定是源的问题，不用怀疑网络带宽。这里省下的时间比省下的钱值钱。

数据卷和端口映射，是 Windows 与 Linux 差异最大的地方

数据卷这块，Linux 上写 -v /data/app:/app 就行，路径是宿主真实路径。Windows 上如果走 WSL2，路径要按 WSL 的规则写，写错了容器会直接报找不到目录。

更省事的做法是用命名卷，让 Docker 自己管存储位置，两边写法一致，也不用操心权限。

端口映射是另一个高频坑。容器内服务监听 127.0.0.1 时，从宿主是访问不到的，必须让它监听 0.0.0.0。这一点在 Windows 上尤其容易踩，因为很多示例配置默认写 localhost。

排查顺序我一般这么走：先 docker ps 看端口有没有映射上，再进容器 curl localhost:端口 确认服务活着，最后从宿主访问。三步走完，问题基本定位。

如果服务要对外提供访问，机器本身的出口带宽和线路质量就成了瓶颈。跑公开服务的话，我会优先选线路稳定的独立服务器，比如 香港服务器12，AMD EPYC 7742 双路 64 核、256G 内存、20M 带宽，月付 $1019.00，适合容器数量多、需要长期稳定在线的场景。个人测试阶段用本地机器就够，不必一上来就上这种配置。

服务器该给多少资源，以及怎么让它开机自己起来

跑几个轻量容器，4 核 8G 是常见起步线。数据库、消息队列这种吃内存的组件单独放一台，别和 Web 服务挤在一起，否则一个容器内存涨上来，整机都受影响。

开机自启在两边写法不同。Linux 上给容器加 restart: always，再确认 docker 服务本身是 systemctl enable docker 过的，重启后容器就自己回来。Windows 上 Docker Desktop 要勾选开机启动，否则机器一重启，容器全停在那不动。

生产环境我建议别只依赖 restart 策略，再配一份 compose 文件放在固定路径，出问题时一条命令重建，比手动一个个启省事。

结论很清楚：本地开发和轻量测试，Windows 加 WSL2 足够用；要长期对外提供服务，直接上 Linux 独立服务器，省掉中间那层转换的麻烦。配置从 4 核 8G 起步，按容器数量和数据库规模往上加，别为了省几百块把数据库和 Web 塞一台机器。