Windows 上用 Docker 跑服务，我踩过的几个坑和一套能落地的流程

很多人在本机装 Docker 是为了先把服务跑起来看看效果，结果第一个小时全耗在启动失败和路径报错上。Windows 这边报错信息往往含糊，Linux 这边又容易在权限和开机自启上翻车。同一套镜像，两个平台踩的坑完全不同。这篇把两种环境分开讲，重点是让容器真正稳定跑起来，而不是只满足于 docker run 能出结果。

Windows 上先确认 WSL2，别急着装 Desktop

Docker Desktop 在 Windows 上默认走 WSL2 后端，但系统自带的内核版本常常偏旧。装之前先在 PowerShell 里跑 wsl --update，再执行 wsl --set-default-version 2。这两步跳过的话，后面拉镜像能成功，容器一启动就报内核不兼容。

Hyper-V 后端我也试过，兼容性不如 WSL2，尤其是挂载宿主机目录时文件变更通知经常失灵。换我我会直接用 WSL2，省掉排查文件同步的时间。

装完之后别急着跑业务容器，先用 hello-world 镜像验证一遍。命令能过，说明守护进程和网络代理都是通的。

数据卷挂载是 Windows 侧翻车最多的地方

Windows 路径写成 C:\data 这种形式，在 docker-compose.yml 里要改成 /c/data 或者用双反斜杠。写成单反斜杠，容器启动时直接报 mount 失败。这个错我见过不少次，报错信息还不提示是路径格式问题。

• 开发阶段用 bind mount 方便改代码，但文件多了之后读写延迟明显，尤其 node_modules 这种目录
• 生产或长期运行的服务，换成具名卷（named volume），数据落在 WSL2 的虚拟磁盘里，性能比挂 Windows 盘符高出一截

还有一点：Docker Desktop 的磁盘镜像默认放在 C 盘，跑几个数据库容器就能吃掉几十 GB。在设置里把镜像位置挪到别的盘，比事后清理省事。

Linux 侧的重点是 systemd 和资源限制

Linux 上装 Docker 简单，apt install docker.io 或者按官方源装都行，麻烦的是让容器跟着系统一起起来。docker run 加 --restart always 只是基础，真正要管好还得写 systemd unit，或者用 docker compose 配合开机任务。

资源限制这块很多人忽略。一台 4 核 8G 的机器上跑三四个容器，不加限制的话某一个吃满 CPU，其他全被拖慢。启动时加 --cpus=1.5 --memory=2g，把边界划清楚，出问题时至少知道是谁在抢资源。

日志也要管。默认的 json-file 驱动不限制大小，跑上几个月能把磁盘写满。在 daemon.json 里配 max-size 和 max-file，单文件 10MB、保留 3 个，够用了。

如果你的服务本身要对外提供访问，宿主机选在离用户近的机房会省掉不少延迟问题。像 香港云服务器 这种 8H8G 配 10M 带宽的配置，跑几个中等负载的容器足够，跨境访问的响应也比绕远路强。

两个平台共用的几条经验

镜像别用 latest 标签。同一个 latest 今天拉和下周拉可能不是同一个东西，回滚的时候找不到对应版本。固定到具体 tag，出问题至少能复现。

环境变量写进 .env 文件，别硬编码在 compose 里。数据库密码这种东西进了 git 历史就很难清干净。

容器里不要跑多个进程。有人图省事把 nginx 和 php 塞进同一个容器，进程管理立刻变成一团乱麻。一个容器一个职责，这是 Docker 设计时就定好的边界。

最后说结论：Windows 适合开发和验证，WSL2 后端是唯一顺手的选项；真正长期跑的服务应该放到 Linux 上，用 systemd 管生命周期，用资源限制防互相拖累。配置能跑通只是起点，能稳定跑三个月才算部署完成。