能让人在 Windows、macOS、Linux 三套系统上顺顺利利把 Docker 跑起来的文章不多因为大多数人只熟悉自己手头那一套环境。Docker 本身是 Linux 容器技术到了 Windows 和 macOS 上都得靠一层虚拟化“壳”顶着这层壳一换坑就全变了。这篇文章不跟你谈概念直接按三平台拆解Windows 上怎么处理 WSL2、macOS 上怎么选对包、Linux 上怎么避开源和权限陷阱再把安装完以后必然会遇到的镜像下载慢、MySQL 8.0 起不来、Docker Compose 编排、PyTorch 训练环境这类高频场景一并讲透。我会把每一步操作背后的“为什么”也讲清楚不是让你背命令是让你在将来遇到新报错时能自己推思路。文里的所有配置和命令都是我在实际项目中跑过、踩过坑以后沉淀下来的版本适合开发者、运维以及所有刚接触容器化、打算用 Docker 搭环境的学习者。1. 动手前先把三个平台的差异搞清楚1.1 同为 Docker底层“壳”完全不同Linux 上跑 Docker 最干净因为容器用的 namespace、cgroup、overlayfs 这些内核特性本来就是 Linux 的。你在 Linux 上装好 docker-ce启动 daemon剩下的就是直接跟内核打交道速度最快、兼容性最好。Windows 上跑 Docker 是个“身份存疑”的过程。Windows 内核不是 Linux没法直接跑 Linux 容器。所以 Docker Desktop 走了两条路老版本用 Hyper-V 虚拟机新版本默认用 WSL2Windows Subsystem for Linux 2。WSL2 本质是一台轻量级虚拟机里面跑了一个精简 Linux 内核Docker 的所有容器最终都运行在这个 Linux 内核上。这也解释了为什么 Windows 上很多诡异问题都出在 WSL2 身上。macOS 上同样没有 Linux 内核Apple 也不允许第三方直接跑 Hypervisor 级别的虚拟化框架所以 Docker Desktop 用的是 macOS 自带的 Virtualization.framework更早版本是 Hypervisor.framework跑一个轻量 Linux VM。Apple Silicon 出来后Docker Desktop 还专门针对 ARM64 架构做了优化但如果你下载错了安装包后果就是启动后不停转圈或直接崩。这三套底层机制决定了你在排查问题时的思路完全不同。Windows 出问题先查 WSL2 和 Hyper-VmacOS 出问题先查芯片架构和资源分配Linux 出问题先查发行版源和系统服务。别拿一套经验套三个平台这是第一课。1.2 选 Docker Desktop 还是替代方案很多人在第一步选型上就栽了跟头。Docker Desktop 对个人用户免费但对企业用户收费。如果你只是学习或者个人项目用Docker Desktop 没问题如果在公司里用不想折腾授权的事可以考虑替代方案。Windows 上可选的替代方案很少基本就是 Docker Desktop 或者裸装 Docker Engine WSL2。裸装方案在 Windows 上维护成本高不推荐新手折腾。macOS 上替代方案多一些常见的有 Colima基于 lima 的轻量 Docker 运行时、OrbStack轻量快速对开发者非常友好、Podman Desktop红帽家的容器工具兼容 Docker CLI。Linux 上就不用说了直接装 docker-ce或者用 Podman 也行。我的建议是新手先老老实实用 Docker Desktop它帮你把 daemon 管理、启动登录、资源分配这些麻烦事都包了。等你对 Docker 的存储驱动、网络模式、挂载行为都有了直观理解再根据需求换 Colima 或 Podman那时候你能看懂它们和 Docker Desktop 的底层差异迁移成本会低很多。1.3 安装前的硬件与系统自检清单很多“装不上”“启动失败”的报错根源是机器配置不达标。我整理过一份自检清单装之前先对着看一遍平台系统要求CPU虚拟化内存建议其他WindowsWindows 10 64位 2004 或 Windows 11需在 BIOS 开启 Intel VT-x 或 AMD-V至少 8GB推荐 16GB需启用 WSL2 和“虚拟机平台”功能macOSmacOS Catalina 以上Big Sur 以后更稳Apple Silicon 无需关注Intel 需确保虚拟化开启至少 8GB推荐 16GBApple Silicon 选 arm64 包Intel 选 amd64 包Linux内核 3.1064位系统无需手动开启但需要内核加载相应模块至少 4GB不同发行版的 docker 包名不同注意区分内存不足是最常见的隐性杀手。Docker Desktop 默认会分配 4GB 内存给你的容器如果你宿主机只有 8GB开几个容器后机器就开始卡。解决方法是装完后去 Settings 里把内存调低或者索性加一条内存条——容器化开发对内存的需求真的比 CPU 高得多。还有一点要提前确认Windows 和 macOS 上如果开着公司电脑的加密软件、EDR 监控软件很可能跟虚拟化组件冲突。这类问题排查起来特别费时间如果怎么装都失败可以先暂时退出安全软件试试很多“玄学问题”就是这么解决的。2. Windows安装八成问题出在 WSL2 上2.1 装 WSL2 的正确姿势顺序和版本都不能错Windows 上安装 Docker Desktop 的前提是 WSL2 已经可用。常见错误是先装 Docker Desktop让它自动检测 WSL结果检测不到报错一堆。正确顺序是先装 WSL2装完重启再装 Docker Desktop。装 WSL2 最简单的方式是以管理员身份打开 PowerShell 或 CMD运行下面这行命令wsl --install这条命令会完成三项工作启用“适用于 Linux 的 Windows 子系统”功能、启用“虚拟机平台”功能、安装默认的 Ubuntu 发行版。运行完重启电脑WSL 内核就绪。如果你的 Windows 版本比较旧wsl --install可能不支持那就走手动安装流程先启用 Windows 功能再下载 WSL2 内核更新包wsl_update_x64.msi最后设版本为 WSL2。整个过程微软官方文档写得很清楚我就不再复制一遍了。装完以后用wsl -l -v查看发行版版本确保显示的是VERSION 2而不是 VERSION 1。如果是 1运行wsl --set-version Ubuntu-22.04 2还有一类情况机器里已经有 VMWare 或 VirtualBox。这些软件和 Hyper-V 的兼容性以前很差现在新版已经好了很多但如果装完 Docker Desktop 一直启动不了可以先关掉 VMWare 的虚拟化引擎试试这就是排查方向。2.2 BIOS 虚拟化没开一切白搭Windows 上遇到“Please enable WSL2 virtualization”“AMD SVM is disabled”这类报错时十有八九是 BIOS 里没开虚拟化。开机时按 DEL、F2 或 F12 进入 BIOS不同主板品牌入口不同找Intel Virtualization TechnologyIntel VT-x或AMD SVM Mode把 Disabled 改成 Enabled保存退出重启。这个开关在主板上的名字五花八门华硕叫“Intel Virtualization Technology”微星叫“SVM Mode”惠普戴尔商用机往往默认关闭需要在“Advanced”或者“Security”菜单里找。有个命令行技巧可以快速确认虚拟化是否已开启同样在 PowerShell 里运行systeminfo输出结果里找到“Hyper-V 要求”那一行如果四个选项全部是“是”说明虚拟化已经就绪如果“虚拟化已在固件中启用”显示“否”那就是 BIOS 的问题不用再折腾系统层面了。还有个更隐蔽的问题Windows 沙盒、内存完整性VBS等安全功能会抢占 Hyper-V 的资源导致 WSL2 分配不到足够的虚拟化能力。如果你开启了这些功能且安装过程中反复失败可以尝试在“Windows 安全中心 - 设备安全性 - 内核隔离”里暂时关闭“内存完整性”再试一次。注意这个操作会影响系统安全仅建议临时排查用。2.3 Docker Desktop 启动失败的典型报错和解决办法我这两年遇到的 Windows 启动问题基本可以归成三类。整理成表方便对照报错/现象根因解决方案“Docker Desktop requires a newer WSL kernel version”WSL2 内核包太旧运行wsl --update更新内核“Docker Desktop failed to deploy infrastructure”WSL 虚拟机状态损坏或残留退出 Docker DesktopPowerShell 里运行wsl --shutdown再重启容器创建后启动即退出日志无内容磁盘空间不足或 Docker Desktop 数据损坏清理磁盘空间在 Settings 里点“Clean / Purge data”重建“Docker Engine stopped”daemon 启动失败多为资源不足或端口被占检查 2375/2376 端口是否被占用调大内存分配Docker 图标反复闪烁无法进入主界面虚拟机平台未启用或 WSL 默认版本不对确认wsl -l -v的 VERSION 是 2并运行wsl --set-default-version 2最常被忽略的是端口占用。Docker daemon 在 Windows 上通过一个内置的 Linux 虚拟机监听端口如果本机装了其他用 2375 端口的软件daemon 有时会启动失败。排查时在命令行运行netstat -ano | findstr 2375把占用进程找出来关掉再重启 Docker Desktop。2.4 WSL2 磁盘膨胀和文件挂载慢的问题Windows 上另一个高频坑是 C 盘空间被 WSL2 的虚拟磁盘文件占用到爆。WSL2 的 Ubuntu 发行版默认存放在C:\Users\你的用户名\AppData\Local\Docker\wsl\下面数据文件是 ext4.vhdx。这个文件只会膨胀不会自动回收。我有一台开发机明明只装了 MySQL 和 Redis 两个容器vhdx 文件却占到了 60GB原因是容器日志和镜像层碎片不断累积。瘦身方法是把 WSL 关掉然后压缩 vhdx 文件。先用管理员身份运行wsl --shutdown接着用 dism 或 PowerShell 找到 vhdx 路径再通过 diskpart 压缩diskpart # 选择 vhdx 文件 select vdisk fileC:\Users\你的用户名\AppData\Local\Docker\wsl\data\ext4.vhdx attach vdisk readonly compact vdisk detach vdisk exit这一步压缩效果很明显能省下来一半空间。以后注意控制容器日志大小运行容器时加--log-opt max-size10m --log-opt max-file3或者改 daemon.json 里的log-driver参数。别等 C 盘红了才想起来。至于文件挂载慢的问题根源在于 WSL2 的文件系统访问跨平台磁盘时走的是 9P 协议性能远不如直接访问 Linux 内部文件系统。你在 Windows 上用-v D:/code:/app挂载一个目录容器里编译、跑测试的速度能差出好几倍。合理做法是把项目代码放到 WSL2 的 Linux 目录里例如/home/你的用户名/workspace然后通过\\wsl$\Ubuntu-22.04\home\...访问或者用 VS Code 的 WSL 插件直接开发挂载性能会好很多。这个问题的完整解法可以在 wsl.conf 里开启 metadata 优化但最彻底的方法还是“数据文件放 Linux 这边”。3. macOS安装Apple Silicon 让事情变简单但坑没消失3.1 芯片不同下载的安装包完全不同macOS 上安装 Docker Desktop 看起来简单官网下载 dmg拖到 Applications完事。但苹果从 2020 年开始从 Intel 转向 Apple Silicon这个芯片差异直接决定你该下载哪一个安装包。在终端运行uname -m输出arm64就是 Apple SiliconM1/M2/M3/M4 等输出x86_64就是 Intel 芯片。Apple Silicon 下载Docker-Desktop-Installer-arm64.dmgIntel 下载amd64版本。下载错了最典型的症状是应用打不开或者打开后一直转圈提示“正在启动 Docker Engine”过几分钟才慢慢好甚至直接闪退。就算下载对了Apple Silicon 上还多一个坑Golang 或 Python 等语言的部分依赖在 arm64 下编译会失败你通过 docker build 构建镜像时可能报“exec format error”。这通常是因为基础镜像没有多架构支持这时需要显式指定平台例如docker build --platform linux/amd64 -t myapp:v1 .或者运行容器时加--platform linux/amd64。虽然走模拟器性能有损耗但兼容性是最稳的。3.2 资源占用太高把 Docker Desktop 的内存调到你用不完的额度macOS 上 Docker Desktop 默认分配的内存是宿主机内存的一半。我见过 16GB 的 MacBook 被 Docker 吃掉 8GB导致浏览器和 IDE 都卡成幻灯片。这个默认值对大多数人来说都偏高了。打开 Docker Desktop 的 Settings - Resources - Advanced把 Memory 调到 4GB 或 6GBSwapping 保持默认即可。CPU 核心数也不用全给留一半给宿主机。如果只是跑 MySQL、Redis 这种轻量服务3GB 内存绰绰有余。另外一个提升体验的小技巧在 Settings - General 里把“使用虚拟化框架”相关的选项勾上Docker Desktop 4.x 默认已经启用然后开启 Resource Saver 模式。这个模式会在没有活跃容器时自动释放大量内存实测下来内存占用能从 6GB 降到 1GB 左右。这个模式特别适合那种“跑完就走”的开发场景。3.3 挂载目录慢、容器内时区不对macOS 上 Docker 的 bind mount 性能问题虽然比 Windows 的 9P 好一些但也没好到哪去。文件监听如 Webpack、Vite 的自动编译在挂载目录里跑经常出现修改了代码不生效、或者保存后要等好几秒才编译的情况。根治方案是把数据放在 Docker volume 而不是 bind mount。例如 MySQL 的数据目录挂 volume 比挂本机某个文件夹要快得多。如果业务上确实需要 bind mount 做代码开发可以考虑把 node_modules 这类临时目录用匿名 volume 覆盖避免文件监听穿透到虚拟机services: frontend: image: node:20 volumes: - .:/app - /app/node_modules容器内部时区不对也是 macOS 用户常遇到的小坑。容器默认时区是 UTC你在日志里看时间比自己电脑慢 8 小时。解决办法是启动时映射本机时区文件或直接设置环境变量docker run -d --name mysql8 \ -e TZAsia/Shanghai \ -v /etc/localtime:/etc/localtime:ro \ mysql:8.0/etc/localtime这个文件在 macOS 上不存在所以如果发现映射失败只用-e TZAsia/Shanghai也能解决大部分问题。MySQL 的日志时区、JVM 的时区在多数镜像里都认这个环境变量。3.4 不想用 Docker Desktop 的话macOS 上还能用什么如果你在公司里用 Docker Desktop 遇到授权弹窗或者就是受够了它占资源和启动慢macOS 上可以换 Colima 或 OrbStack。Colima 是一个基于 lima 的轻量容器运行时很多人称它为“免费版 Docker Desktop”。安装方式是用 Homebrewbrew install colima docker docker-compose colima start --memory 4 --cpu 2启动之后Docker CLI 会通过~/.docker/config.json自动连到 colima 的 socket跟 Docker Desktop 的使用体验完全一致。Colima 的好处是免费、开源、体积小缺点是界面少了没有 GUI 面板daemon 日志要用colima status和colima ssh去看。如果你能接受命令行为主的工作流Colima 是很好的替代品。OrbStack 则是更轻量的商业方案对开发者友好速度确实比 Docker Desktop 快不少但需要付费订阅。两个方案我都用过一段时间个人结论是以命令行为主选 Colima偏好可视化界面又不想用 Docker Desktop 就选 OrbStack。4. Linux安装看起来最简单坑都在细节里4.1 不同发行版的 Docker 包名和源不一样Linux 上跑 Docker 看起来是三条命令的事sudo apt update sudo apt install docker.io sudo systemctl start docker但这里藏着一个很大的坑Ubuntu/Debian 自带的docker.io是发行版维护的 Docker 旧版本很多新特性不支持而且老版本会有已知漏洞。该装的是 Docker 官方维护的docker-ceCommunity Edition。安装 docker-ce 的正确方式是先加入 Docker 官方 apt 仓库。我见过很多人图省事直接apt install docker.io结果后来跑新镜像、用新 Dockerfile 指令时各种报错最后又花一晚上搬家到 docker-ce。建议你从一开始就选择官方仓库省得返工sudo apt update sudo apt install -y ca-certificates curl gnupg sudo install -m 0755 -d /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg sudo chmod ar /etc/apt/keyrings/docker.gpg echo \ deb [arch$(dpkg --print-architecture) signed-by/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \ $(. /etc/os-release echo $VERSION_CODENAME) stable | \ sudo tee /etc/apt/sources.list.d/docker.list /dev/null sudo apt update sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin注意最后一行我特意装了docker-buildx-plugin和docker-compose-plugin。现在新版 Docker 已经内置了 buildx 和 compose v2不需要再单独安装旧版docker-compose那个是 Python 写的性能差很多。CentOS/RHEL/Fedora 上则是用 dnf 或 yum 装docker-ce源配置方式类似只是包管理器换成 dnf。国产发行版如 openEuler、麒麟这类系统官方 Docker 源不一定有对应代号可以直接下载 rpm 包安装或者用阿里开源镜像站提供的 docker-ce 源这个后面统一说。4.2 为什么要配镜像加速器下载慢的根源和解法镜像下载慢是所有人都会遇到的问题。根因是 Docker Hub 服务器在海外网络链路走公网尤其在没有特殊手段的情况下拉取 mysql:8.0 这种几百 MB 的镜像能慢到让你怀疑人生。解法是给 Docker daemon 配置 registry mirror镜像加速器让 Docker 从国内的开源镜像站拉取镜像。这个配置对三个平台都适用我就统一在这里讲了。创建或修改/etc/docker/daemon.json{ registry-mirrors: [ https://docker.mirrors.ustc.edu.cn, https://mirror.ccs.tencentyun.com ] }阿里云加速地址是每个用户独立的登录阿里云容器镜像服务控制台 → 镜像加速器会分配一个专属 HTTPS 地址填入列表第一项效果最好。不同镜像站的同步时间略有区别如果你拉某个镜像发现不是最新版本换个源多试一次就行。改完以后重启 daemon 生效sudo systemctl daemon-reload sudo systemctl restart docker验证是否生效用docker info | grep -A1 Registry Mirrors能看到自己配置的地址就说明成功了。这个配置也是所有平台通用的Windows 和 macOS 的 Docker Desktop 里在 Settings - Docker Engine 里直接编辑 JSON 即可效果一样。4.3 普通用户免 sudo 运行 Docker安全性和便利的取舍在 Ubuntu 上刚装完 docker-ce运行docker ps会出现“permission denied while trying to connect to the Docker daemon socket”的报错。这是因为/var/run/docker.sock这个 socket 文件默认只有 root 用户和 docker 组的用户可以访问。把当前用户加入 docker 组就可以不用每次敲 sudosudo usermod -aG docker $USER然后重新登录或执行newgrp docker让组权限生效。之后docker命令就能直接用了。但这里提醒一句加入 docker 组等价于给予该用户 root 级权限因为 docker socket 可以操作宿主机任意文件。这是 Docker 官方文档明确警告过的。只在个人开发机上这么配没问题服务器上请务必控制加入 docker 组的用户范围或者坚持用 sudo。我有个朋友在公司服务器上给所有开发都加了 docker 组结果有一次某同事误操作docker run -v /:/host容器里执行了删除命令差点把宿主机搞挂。这类事故不是吓唬人Docker 的权限边界你要心里有数。4.4 systemd、防火墙、IPv6 和 cgroupLinux 特有的四个隐藏麻烦Linux 上装完 Dockerdaemon 正常启动了但你可能会遇到几个“查不到原因”的怪问题。第一个是 systemd 与 docker 服务的关系。Docker 默认用cgroupfs作为 cgroup 驱动而 systemd 作为 PID 1 时也管理 cgroup。单机跑 Docker 没多大问题但如果你后面要部署 Kuberneteskubeadm 方式kubelet 会要求 cgroup driver 统一为 systemd。到那时修改 daemon.json{ exec-opts: [native.cgroupdriversystemd] }改完重启 docker 就好。这个配置提前知道以后用 K8s 能少踩一个大坑。第二个是防火墙。Ubuntu 装上 docker-ce 后默认防火墙 ufw 可能没有放行容器的端口映射。如果你用的是 Docker 默认的-p 3306:3306映射外部机器访问宿主机 3306 端口没反应先在宿主机上确认sudo ufw allow 3306/tcp sudo ufw reloadCentOS 上同理用 firewalldsudo firewall-cmd --permanent --add-port3306/tcp sudo firewall-cmd --reload还有一点要注意Docker 默认会把容器网络伪装到宿主机后面所以如果容器里面访问外网不通一般不是 Docker 的问题而是宿主机的 IP 转发没开启。检查/proc/sys/net/ipv4/ip_forward返回值是不是 1如果是 0执行sudo sysctl -w net.ipv4.ip_forward1第三是 IPv6。Docker 默认的 bridge 网络只开了 IPv4如果你的容器需要访问 IPv6 地址要在 daemon.json 里开启 IPv6{ ipv6: true, fixed-cidr-v6: 2001:db8:1::/64 }这个需求不多见但真遇到时能想到排查方向就够了。最后是容器日志膨胀问题这个我在前面 Windows 那节已经提到了Linux 上也一样记得给 daemon.json 加上日志轮转配置{ log-driver: json-file, log-opts: { max-size: 10m, max-file: 3 } }这一项强烈建议一装完就配上等容器跑几个月后再去清理上 GB 的日志文件你会后悔没早配。5. 绕不开的经典场景MySQL 8.0、Compose 和 PyTorch 环境5.1 一条命令跑起 MySQL 8.0但你要懂每个参数环境搭好了总得跑点真实服务验证一下。MySQL 8.0 是出现频率最高的容器实验对象。很多人照着网上命令跑却因为参数理解不到位后面连不上数据库时不知道怎么排查。我先给一条“能直接用于开发环境”的完整命令docker run -d \ --name mysql8 \ -p 3306:3306 \ -e MYSQL_ROOT_PASSWORDyourpassword \ -e TZAsia/Shanghai \ -v mysql8-data:/var/lib/mysql \ --restart always \ mysql:8.0逐个解释每个参数的含义-d后台运行容器。--name mysql8给容器起名叫 mysql8后面想停止、查看日志都用这个名字而不是容器 ID。-p 3306:3306把宿主机 3306 端口映射到容器 3306 端口。左侧是宿主机端口右侧是容器端口。如果本机 3306 已被占用把左侧改成 3307 就绕开了。-e MYSQL_ROOT_PASSWORDyourpassword设置 MySQL root 密码。首次创建数据卷时MySQL 镜像的初始化脚本会读这个环境变量初始化 root 密码。如果数据卷已经存在改这个环境变量不会影响已有密码这也是很多人“怎么改密码都不生效”的原因——数据卷已经初始化过了。-TZAsia/Shanghai设置容器时区让 MySQL 时间跟本地一致。-v mysql8-data:/var/lib/mysql用命名卷持久化数据。容器删了重建数据还在。--restart always让 Docker daemon 启动时自动拉起这个容器。服务器重启后不用手动启动 MySQL非常省心。跑起来以后验证一下docker ps docker exec -it mysql8 mysql -uroot -p能进 MySQL 命令行就通了。有个经典坑是MySQL 8.0 默认认证插件是caching_sha2_password旧版 MySQL 客户端如 5.x 自带的 mysql 命令连不上报错“Authentication plugin caching_sha2_password cannot be loaded”或“Access denied for user”。解决办法是创建用户时显式指定认证插件CREATE USER app% IDENTIFIED WITH mysql_native_password BY apppass; GRANT ALL PRIVILEGES ON *.* TO app%; FLUSH PRIVILEGES;这句话 2023 年以后的连接器基本都不需要了新版客户端支持 caching_sha2_password但老系统迁移到 Docker 环境时这个坑还是值得记一下。5.2 Docker Compose从“一条命令”到“一个文件启动一堆服务”单独跑 MySQL 还好一旦需要 MySQL Redis 后端服务 前端服务你还用docker run一条条敲维护成本就失控了。这时候 Docker Compose 就该出场了。Compose 的思路是用一个 YAML 文件描述多个容器的“编排关系”一条docker compose up -d就能全部启动。我用得最频繁的例子是一套“MySQL Redis”的开发环境Compose 文件长这样services: mysql8: image: mysql:8.0 container_name: mysql8 restart: always ports: - 3306:3306 environment: MYSQL_ROOT_PASSWORD: root123456 TZ: Asia/Shanghai volumes: - mysql8-data:/var/lib/mysql redis: image: redis:7 container_name: redis7 restart: always ports: - 6379:6379 command: [redis-server, --appendonly, yes] volumes: mysql8-data:在项目目录下保存为docker-compose.yml然后执行docker compose up -d就同时把 MySQL 8.0 和 Redis 7 拉起来了。以后镜像更新、配置修改改 YAML 文件后docker compose up -d就会增量重建变化的服务其他服务不受影响。停止全部服务用docker compose down注意这会删掉容器但命名卷里的数据还在。这里提醒一下 compose 文件格式。新版 Docker Compose v2 不需要写version:字段了写上去反而容易误导人。services 下面的缩进必须用空格不能用 Tab。YAML 解析失败时最常见的报错就是 “mapping values are not allowed here”多数是缩进混乱用docker compose config可以提前做校验。5.3 用 Docker 搭 PyTorch 训练环境GPU 怎么传进容器机器学习课程里最常见的一个需求就是把 PyTorch 环境跑起来还会涉及 GPU 加速。Docker 在这块的坑比前面所有平台问题加起来都多核心痛点在于GPU 不能像 CPU 内存一样直接共享需要一套额外的运行时支持。Linux 上要让容器用上 NVIDIA GPU先要安装 nvidia-container-toolkitsudo apt install -y nvidia-container-toolkit sudo systemctl restart docker装好之后运行 PyTorch 官方镜像是这样的docker run --gpus all -it --rm \ --shm-size8g \ -v $(pwd):/workspace \ pytorch/pytorch:2.5.1-cuda12.1-cudnn9-runtime \ bash--gpus all参数把宿主机所有 GPU 传递给容器。这一步依赖刚才装的 toolkit如果没装运行时会报“could not select device driver with capabilities: [[gpu]]”这句报错基本就是 toolkit 没装好或 docker 没重启的提示。--shm-size8g是第二个高频坑。PyTorch 的 DataLoader 多进程模式会使用/dev/shm共享内存容器默认只有 64MB一旦数据加载线程一多立刻报“Bus error”或“DataLoader worker (pid xxx) is killed by signal: Bus error”。这时候调大 shm 就解决了。还有一点要提醒PyTorch 官方镜像很大通常要 5GB 以上拉取时间长很正常。配合前面说的镜像加速器会好很多。macOS 和 Windows 上即便你是 NVIDIA 显卡几乎是不可能把 GPU 透过 Docker Desktop 传给容器的。如果你必须在本地做 GPU 训练建议还是在 Linux 宿主机上跑或者用 WSL2 里的 Linux 环境跑 Docker GPUWindows 11 上这个方案成熟度已经可以但依然踩坑多于纯 Linux。6. 高频问题速查表与踩坑心得6.1 按平台整理的问题速查表把这三平台这几年我见过、踩过的高频问题汇总成速查表遇到报错先来这里翻一眼平台现象排查方向解决操作Windowsdocker 命令不存在Docker Desktop 没启动或 PATH 没配启动 Docker Desktop确认小鲸鱼图标在运行WindowsWSL 报错 VERSION 1默认 WSL 版本不是 2wsl --set-default-version 2Windows容器跨目录挂载卡顿WSL2 9P 协议性能瓶颈项目代码移入 WSL2 文件系统避免挂载 Windows 目录macOSDocker app 闪退或转圈下载的安装包架构不对uname -m确认芯片重新下载匹配安装包macOS容器内时间戳差 8 小时容器时区默认 UTC-e TZAsia/Shanghai或映射/etc/localtimeLinux外网访问不到容器服务防火墙没放行端口ufw / firewalld 放行对应端口Linux普通用户权限不足socket 权限未授权加入 docker 组注意权限风险通用镜像拉取超时没配镜像加速器配置 daemon.json 的 registry-mirrors通用容器日志撑爆磁盘日志轮转没配加 log-opts 配置并重启 daemon通用MySQL 客户端连不上 8.0认证插件不匹配创建用户时指定mysql_native_password这张表我自己打印过贴在工位上排查问题能省一半时间。6.2 几个亲测有效的排查技巧最后分享几个我压箱底的排查思路不一定写在 Docker 官方文档里但每次都救我于水火。第一个是“看日志永远先从 Docker daemon 日志看起”。在 Linux 上这个命令是journalctl -u docker -fWindows 和 macOS 上Docker Desktop 的日志在“troubleshoot”界面里可以一键导出。很多人遇到问题直接搜报错文本但其实 daemon 日志里往往有更具体的线索。比如容器启动失败先用docker logs 容器名看容器自身日志再看docker inspect 容器名的 State 和 ExitCode最后才轮到网上去搜。这样定位比瞎猜快太多。第二个是“用 docker compose 代替裸 docker run 做实验”。每次跑容器时顺手写成 compose 文件哪怕只有一个服务也是个好习惯。原因很简单docker run 敲完就没了参数全靠记compose 文件把环境变量、挂载、端口、重启策略都写成代码下次重建环境时直接复用。时间久了你会发现自己积累的 compose 文件就是一套“可版本化的开发环境配置”。第三个是关于清理的。开发机环境脏了以后磁盘占满、镜像冲突、容器残留的问题特别多。定期执行docker system prune -a会删掉所有不为任何容器所用的数据包括悬空镜像、停止的容器、未使用的网络和缓存。这个命令在磁盘快满时特别好使能清出几个 GB 的空间。但注意后面别加-v-v会连命名卷一起删掉万一那个卷里是你 MySQL 的唯一数据那就是事故了。第四个也是我个人体会最深的一点安装 Docker 这类基础设施时不要追求“一次成功”。环境越杂失败越正常。关键是失败以后能不能按系统化的思路一步步排除问题。Windows 先查 WSL2 再查 BIOSmacOS 先查架构再查资源Linux 先查源再查权限和防火墙顺着这个顺序来大部分问题都能自己解决。把每次报错的截图、日志存下来过三个月回看你会发现自己对 Docker 的理解已经远超那些只会照抄命令的人。