Docker部署从Windows到Linux：我踩过的配置坑与迁移思路
本地用Windows写代码、线上跑Linux服务器，这是很多独立开发者和中小团队的常态。麻烦的地方在于：同一套Docker配置，在Windows上能跑，推到Linux服务器上就报错——路径写法不一样、权限对不上、镜像拉取慢到超时。更头疼的是，Windows上Docker Desktop吃内存太狠，开两三个容器机器就开始卡。这篇把两套环境的部署流程分开讲清楚，再说说从Windows迁移到Linux服务器时哪些地方最容易翻车。
Windows上装Docker：先想清楚用WSL2还是Hyper-V
Windows装Docker Desktop，安装程序会让你选后端。默认推荐WSL2，我一般也建议选它。
WSL2是真正的Linux内核，跑容器比Hyper-V虚拟机的性能损耗小得多。而且WSL2支持文件系统互通，你在Windows里改代码，容器里能直接看到。
选Hyper-V的话，Docker会起一个完整的虚拟机，内存分配是硬性的。你给虚拟机分了8G，这8G就被占住了，不会还给你。WSL2是动态分配，用多少拿多少，对内存紧张的开发机更友好。
装完之后记得做两件事：
- 在Docker Desktop设置里把WSL2的磁盘镜像挪到非系统盘，默认放在C盘用户目录下，时间长了镜像和容器数据能吃掉几十G。
- 配置国内镜像加速器。Docker Hub在国内拉取速度经常只有几十KB/s，一个几百M的镜像要等十几分钟。在设置里的Docker Engine配置中加入registry-mirrors，速度能提到几MB/s。
WSL2有个坑：它默认的内存上限是宿主机的50%。如果你的机器是16G内存，WSL2最多用8G，跑几个容器就顶到头了。可以在用户目录下建一个.wslconfig文件，手动指定memory=12GB，让WSL2能多用一些。
Linux服务器上装Docker Engine：别用发行版自带的老版本
到了Linux服务器这边，情况比Windows简单，但有个容易忽略的点：很多发行版的软件源里自带的Docker版本太老，可能还是几年前的。用apt install docker.io装出来的版本，跟最新的Docker Compose语法可能对不上。
正确的做法是走Docker官方的安装脚本，或者手动添加官方源。装完之后确认版本，Docker Engine 24以上、Compose V2才算比较新。
Linux上还有几个必做的配置：
- 把当前用户加入docker组，否则每条docker命令都要加sudo，用起来很别扭。
- 配置镜像加速，方法跟Windows一样，改/etc/docker/daemon.json。
- 设置Docker开机自启，systemctl enable docker，不然服务器重启后容器全没了。
如果服务器在国内，拉取镜像慢是常态。除了配加速器，还可以考虑把常用镜像先拉到本地再导出成tar文件，传到服务器上导入。这个方法笨但管用，适合镜像体积大、网络又不稳定的情况。
对于需要长期跑多个容器的场景，一台配置稳定的物理服务器比云主机更划算。秀米云的香港物理服务器 I，E3-1230配8G内存，月付$87，跑十几个轻量容器没什么压力，网络延迟对国内访问也友好。
从Windows迁到Linux：路径、权限、网络这三处最容易出错
本地开发跑通了，往Linux服务器上迁的时候，最容易出问题的地方我按踩坑频率排一下。
第一是文件路径。Windows用反斜杠，Linux用正斜杠，这个大家都知道。但更隐蔽的是Docker卷挂载的路径写法。在Windows的Docker Desktop里，你可以写./data:/app/data这样的相对路径，它能识别。到了Linux上，如果docker-compose.yml文件位置变了，相对路径的基准就跟着变，容器可能挂载到一个空目录，数据全丢。
我一般建议在docker-compose.yml里统一用绝对路径，或者用命名卷代替绑定挂载。命名卷由Docker管理，不依赖宿主机目录结构，迁移时直接用docker volume create重建就行。
第二是文件权限。Windows的文件系统没有Linux那套UID/GID概念，容器里以非root用户运行时，挂载Windows目录经常遇到权限拒绝。Linux上虽然也有权限问题，但至少你能用chown和chmod去修。从Windows迁过来的时候，记得检查容器内运行用户的UID，跟宿主机挂载目录的属主是否匹配。
第三是网络模式。Windows上Docker Desktop的网络是经过一层NAT转发的，容器端口映射到宿主机，外部访问没问题。但如果你在容器里需要访问宿主机的服务，Windows上得用host.docker.internal这个特殊域名。Linux上直接用宿主机IP就行，或者用host网络模式。这个差异在配置数据库连接、缓存服务地址的时候特别容易忘。
迁移的时候还有个实际问题：镜像的架构。如果你在M1/M2芯片的Mac上构建镜像，推到Linux x86服务器上跑不了，架构不匹配。Windows上如果是ARM设备也一样。构建的时候要指定--platform linux/amd64，或者在服务器上重新构建。
部署完之后的日常维护：日志、更新和资源限制
容器跑起来只是开始，后面还有几件事得盯着。
日志是最容易失控的。Docker默认不限制容器日志大小，一个跑了几周的容器，日志文件能到几个G，把磁盘写满。在docker-compose.yml里给每个服务加上logging配置，限制单个日志文件大小和保留数量，比如max-size: 10m、max-file: 3。
资源限制也建议加上。特别是内存，不限制的话某个容器内存泄漏能把整台服务器拖垮。在compose文件里用deploy.resources.limits指定memory和cpus，配合restart: unless-stopped，容器崩了能自动拉起来。
更新镜像的时候，别直接docker pull latest然后重启。latest标签的内容随时会变，今天拉的和下周拉的可能是两个版本。生产环境建议用具体版本号标签，更新前先在一台测试机上跑一遍。
如果容器数量多、又想省去手动管理镜像和网络的麻烦，上一台独立服务器自己管会更省心。秀米云的香港自营国际物理服务器③，双E5-2650L共16核32线程、32G内存、100M带宽，月付900元，适合跑一二十个容器还有余量的场景。
最后给个直接结论：本地开发用Windows + Docker Desktop + WSL2后端，把镜像加速配好，日常够用。上线部署老老实实选Linux服务器，装官方源的Docker Engine，compose文件里路径用绝对路径或命名卷、加日志和内存限制。从Windows往Linux迁的时候，重点检查挂载路径、文件权限和网络模式这三处。容器规模超过十个、又不想被云主机的资源上限卡住，一台8G到32G内存的独立服务器月付几十到几百美元，比按量计费的方案更可控。