Docker 部署环境怎么配：Windows 与 Linux 两条路的取舍
很多人第一次装 Docker 是在自己电脑上，Windows 装完 Docker Desktop，敲一句 hello-world 就出结果，心里觉得这事挺简单。等到买了台服务器准备上线，SSH 上去照着同样的步骤做，发现容器起了、端口也映射了，浏览器就是打不开。问题往往不在 Docker 本身，而在两套系统的网络模型根本不一样：Windows 底下跑的是虚拟机里的一层 Linux，端口由 Docker Desktop 代管；Linux 上是内核直接跑容器，流量要穿过 iptables 或者 nftables。同一份 docker run 命令，在两边的实际效果能差出十万八千里。下面把两条路的安装、加速、映射和上线检查分开说，顺带讲清楚哪些步骤能省、哪些省了后面要加倍还回来。
Windows 上装 Docker：先想清楚是本地调试还是长期跑服务
Windows 这条路的坑，多数出在选错后端。Docker Desktop 装好后可以在设置里切 WSL2 后端和 Hyper-V 后端，默认给的是 WSL2。我一般建议直接留在 WSL2，原因很实际：它和 Windows 文件系统之间的读写开销比 Hyper-V 共享目录小得多，挂载项目代码进去时差别肉眼可见。如果你的项目放在 C 盘用户目录下，容器里读文件会明显慢，把代码挪到 WSL 的 ext4 分区里再挂载，构建速度差别很大。
安装本身没什么技术含量，去官网下安装包，双击，勾选 WSL2 组件，重启。真正的取舍在资源分配。Docker Desktop 默认会吃掉不少内存，WSL2 后端下可以在用户目录建一个 .wslconfig 文件，把内存上限和 CPU 核数写死。一台 16GB 内存的开发机，给 WSL 分 8GB 通常够用；给满 16GB，宿主机自己会卡。
- 本地开发、单机调试：Docker Desktop + WSL2 后端，够用
- 要长期跑生产服务：换 Linux 服务器，Windows 上跑容器只适合开发
为什么长期服务不建议留在 Windows？授权是一层，稳定性是另一层。Windows 更新重启会打断所有容器，而 Linux 上你可以控制什么时候重启内核。省下迁移那点功夫，换回的是半夜被更新打断的风险。
Linux 装 Docker：用官方源还是发行版自带仓库
Linux 上装 Docker 有两条路，差别不小。发行版自带仓库里的 docker.io 版本通常落后几个大版本，buildkit 的新特性、compose 的子命令都对不上；官方源给的是最新稳定版，代价是你得自己加 GPG key 和软件源。我一般走官方源，多敲三行命令，换回来的是版本可控。
国内机器拉镜像慢是常态，配加速器几乎是必做步骤。写进 /etc/docker/daemon.json，重启服务生效。这里有个常被忽略的点：加速器不是越多越好，列表越长，Docker 逐个超时重试的时间越久，反而更慢。留两三个稳定的就够，剩下的删掉。
装完之后建议先做一次验证，别急着上项目：
- docker info 看存储驱动，overlay2 是常见选择
- docker run --rm hello-world 确认拉取和运行链路通
- systemctl enable docker 保证重启后自动起
存储驱动这块，如果宿主机用的是比较新的文件系统，Docker 一般会自动选 overlay2，不用手动干预。手动改反而容易出问题。
端口映射与防火墙：容器通了、外面打不开，多半卡在这一步
这是最容易花时间的一节。容器里服务监听 0.0.0.0:8080，docker run 写了 -p 8080:8080，在 Linux 上执行 docker ps 看到映射正常，curl 本机 127.0.0.1:8080 也通，但从外网访问就是超时。多数情况下问题出在两层：云服务商的安全组，以及宿主机自己的防火墙。
安全组要先放行端口，这一步在控制台做。宿主机防火墙这块，用 firewalld 的机器要注意，Docker 会自己往 iptables 里插规则，经常绕过 firewalld 的管理，导致你以为端口封了其实开着，或者反过来。用 ufw 的机器同理，Docker 发布的端口默认不受 ufw 规则约束。我一般会把要暴露的端口在防火墙和 Docker 两处都确认一遍，而不是只信一处。
另一个高频问题是绑定地址。容器里的服务如果监听的是 127.0.0.1，那映射到宿主机也没用，外部流量进不来。改配置让它监听 0.0.0.0，或者用反向代理在前面兜一层。
到这一步，机器的规格就开始影响体验了。构建镜像吃 CPU 和内存，跑多容器吃内存带宽。如果打算在一台物理服务器上同时跑几个服务，配置别压得太紧。像 香港大带宽服务器 XIII 这种 E5-2683v4*2 / 64G 的配置，跑容器编排和几个常驻服务余量比较足，G 口带宽在拉取镜像和对外服务时也不容易成为瓶颈。预算紧一些的场景，香港自营物理服务器(20M)④ 的 E5-2686V4 十八核三十六线程配 32G 内存，月付 ¥1350，跑中等规模的容器集群够用，代价是 20M 带宽在镜像分发高峰期会紧一点。
上线前的检查清单与常见返工点
配置跑通不等于可以上线。我见过不少返工都发生在重启之后：容器没设 restart 策略，宿主机一重启服务就没了。docker run 加 --restart unless-stopped，或者写在 compose 文件里的 restart 字段，二选一，别漏。
数据卷也是重灾区。容器里的数据如果不挂出来，删容器等于删数据。生产环境我一般会明确指定宿主机目录挂载，而不是用匿名卷，出问题时知道数据在哪。
日志同样要提前想。默认的 json-file 驱动不限制大小，跑几个月能把磁盘写满。在 daemon.json 里配 max-size 和 max-file，或者接日志驱动转发出去。这一步花五分钟，能省掉一次磁盘写满导致的故障排查。
最后是镜像来源。开发时随手 docker pull 一个 latest，上线时版本漂移会让人头疼。固定 tag，别用 latest，这条在两边系统上都适用。
回到最初的选择：本地开发留在 Windows 上用 Docker Desktop，图的是顺手；真正对外提供服务，换到 Linux 物理服务器上，图的是可控。两套系统都要配镜像加速、都要检查端口映射，区别在于 Linux 上你得自己管防火墙和 iptables，Windows 上这些被 Docker Desktop 包了一层。想省心就用托管方案，想省钱就自己配，但端口和重启策略这两件事，在哪边都别省。