工欲善其事必先利其器这话放在 Docker Desktop 上特别接地气。上一回我们把环境跑起来基础命令也能凑合用了但真正到了项目开发里光“能跑”远远不够。镜像怎么拉、卷怎么挂、网络怎么通、磁盘怎么清这些问题不顺手容器就会从“开发利器”变成“效率绊脚石”。这篇我来聊下半部分把平时用 Docker Desktop 干活时最常碰到的场景、参数、坑和对应的处理办法一次说清楚。文章不追求炫技也不堆命令所有内容都是按真实项目里会用到的顺序组织的适合已经装好 Docker Desktop、正在尝试把它用进日常开发的读者。1. 从“能跑”到“顺手”这篇到底补什么1.1 上篇攒下的家底这篇怎么用起来上篇我写了怎么把 Docker Desktop 装好、怎么把最基本的容器命令跑通。可实际写代码的时候没人天天跑 hello-world。你真正面对的是这些问题数据库要不要塞进容器里代码改了容器里为什么没变化磁盘空间怎么又少了几个 G两个容器之间怎么互相访问这篇的定位很简单就是把 Docker Desktop 从“偶尔拿来试一下的玩具”变成“每天离不开的开发工具”。要做到这一步光会 docker run 还不够你得把镜像、数据卷、网络和资源限制这四件事串起来。我见过不少朋友Docker Desktop 装了好几个月还停留在拉镜像、开容器、用完就退的阶段遇到问题只能删了重建重建完数据又丢了挫败感很强。我自己日常使用容器的思路大概分三层。第一层临时跑个依赖服务比如启动一个 redis一条 docker run 命令就搞定用完直接删不心疼。第二层固定组合的项目比如后端服务加 redis 加 postgres写进 compose 文件一条命令把完整环境拉起来。第三层代码要和容器保持同步联调把本机源码目录绑定挂载进容器改完代码容器里马上生效。这三层对应的是不同的操作习惯后面的所有细节也都是围绕这三层展开的。1.2 使用场景分层决定容器策略初学者最容易犯的错是把所有容器都当成“临时虚拟机”来用启动参数随手写数据随便放退出靠 CtrlC最后留下一堆状态不明的容器和一堆不知道属于谁的卷。我的建议是动手之前先回答三个问题。第一个这个项目是临时调试一下还是要长期开发临时调试就单容器跑不要写 compose长期开发就把依赖、存储、端口映射全部用配置文件固定下来。第二个需不需要保留数据会写文件的服务比如数据库、消息队列、缓存数据卷必须用命名卷接住。第三个要不要让多个容器互相通信只要超过一个容器就别再想着用 IP 互连直接上自定义网络或 compose。这三个问题想明白后面很多参数就不需要死记硬背。比如你只是临时跑一个 redisdocker run -d --name dev-redis -p 6379:6379 redis:7-alpine 就够但如果你想把它作为一个项目的固定组件写进 compose 文件、配好命名卷和自定义网络才是正确姿势。2. 镜像、容器与数据卷绕不开的核心细节2.1 镜像选择与构建的实战逻辑镜像这块最容易被忽视也最容易埋雷。很多新手习惯直接 docker pull node:latest或者 Dockerfile 里写 FROM node:latest。latest 最大的问题不是“版本不稳定”而是你无法预期今天拉到的和明天拉到的到底是不是同一个东西。换台机器、隔段时间再构建环境就对不上了。更稳的做法是每次都用带完整版本号的镜像比如 node:20-bookworm-slim。基础镜像怎么选我有一条经验总结可供参考能用 slim 就不用 full能多阶段构建就别把所有工具链留在最终镜像里。slim 版本去掉了很多不必要的文件体积能小不少镜像层更干净攻击面也小。真正需要编译的项目就用多阶段构建。举个很典型的例子一个 Go 服务最终运行只需要一个二进制文件完全不需要开发环境里的编译器、依赖源码和调试工具。可以这样写FROM golang:1.22 AS builder WORKDIR /src COPY . . RUN CGO_ENABLED0 go build -o app . FROM alpine:3.19 COPY --frombuilder /src/app /usr/local/bin/app CMD [app]第一阶段负责编译第二阶段只拷贝编译结果最终镜像里只有一个精简系统加一个二进制文件。这个做法把“构建环境”和“运行环境”拆开是生产镜像的基本功本地项目同样适用好处是拉取快、占用小、依赖少。还有一个容易被忽略的点Dockerfile 里的每一行指令都会产生一层镜像层放得越多构建和拉取就越慢。构建缓存是否命中也和指令顺序直接相关。把不常变的操作放前面把频繁变化的代码 COPY 放后面能最大化缓存命中率。我见过有人把 COPY package.json 和 RUN npm install 放在文件末尾结果每次改代码都要重新编译依赖构建速度惨不忍睹。正确顺序应该是先设置基础环境再 COPY 依赖清单文件然后安装依赖最后 COPY 源码。2.2 数据卷与挂载容器删了数据不能没容器本身是临时性的删了重建是家常便饭但数据不能跟着没了。Docker 里有三种保存数据的方式绑定挂载、命名卷、匿名卷。绑定挂载是把本机目录直接映射进容器适合放源码因为你要频繁编辑。命名卷由 Docker 管理数据其实存放在 Docker 数据目录里适合放数据库文件这类不希望直接动的内容。匿名卷是你没起名字的卷容器删除后容易变成悬空卷建议尽量避免。我的习惯是源码用绑定挂载数据库和缓存的数据用命名卷。举个例子启动一个 postgres数据存到 pg_data 命名卷里docker volume create pg_data docker run -d --name dev-postgres \ -v pg_data:/var/lib/postgresql/data \ -e POSTGRES_PASSWORDsecret \ -p 5432:5432 \ postgres:16-alpine之后不管容器删多少次只要命名卷还在数据库内容就还在。挂载还有一个高频坑文件权限。容器内进程默认以 root 身份运行本机登录用户通常不是 root两边写同一个文件时 uid 对不上就会出现在宿主机建的文件容器里读不了、容器里生成的文件宿主机删不掉的诡异现象。我的处理办法比较直接在 Dockerfile 里尽量用 USER 指令指定一个非 root 运行用户如果某个镜像不支持那就在启动时用 user 参数映射 UID。实在不想折腾权限至少保证挂载目录本身不是只有 root 可以读写。再提醒一点不要把你本机的 node_modules 直接挂进容器。不同操作系统的原生模块并不通用你把 Linux 容器里 npm 安装的结果和 Windows 上的 node_modules 混在一起轻则热更新失效重则直接启动报错。正确的做法是挂载源码目录依赖安装放到容器内完成如果确实需要绕过这个问题可以在 compose 里用一个匿名卷覆盖容器内的依赖目录让依赖和源码分离。2.3 网络模式何时用 bridge何时用 host何时自定义Docker Desktop 默认会创建一个 bridge 网络单个容器通过它与外界通信。如果你只是想把某个端口暴露出来比如把容器里的 8000 映射到本机的 8000直接用 -p 8000:8000 就够了简单直接。但是一旦有两个容器需要互相访问很多人就开始犯迷糊。记住一个关键点容器里访问另一个容器的 localhost 是不可行的因为每个容器都有自己的网络命名空间localhost 指的就是容器自己。最蠢的绕法是去查对方的 IP 地址然后写死在配置里IP 一变就崩。正确做法是创建一个自定义 bridge 网络多个容器加入同一个网络后直接用服务名当主机名互相访问。比如 web 容器要连 redis连接地址写 redis:6379 而不是 127.0.0.1:6379。即使容器重启、网络重建连接关系也不会断。具体操作可以这样docker network create dev-net docker run -d --network dev-net --name redis redis:7-alpine docker run -d --network dev-net --name app --expose 8000 your-imageapp 镜像里的配置Redis 地址写 redis 就可以了。这是这套机制里最核心的一点建议自己动手起两个容器验证一下比看十遍文档都管用。host 模式在 Docker Desktop 上反而没那么常用。原因不复杂Docker Desktop 本质上是跑在虚拟化环境里的host 模式并不能像纯 Linux 环境那样真正共享宿主机网络栈。所以我的态度很明确在 Docker Desktop 环境里优先用自定义网络不要为了用 host 模式而去学它的更多细节。如果你使用 docker compose 起多个服务自定义网络已经被工具自动创建好了。compose 会为整个项目创建一个独立网络文件里声明的每个服务都能直接用服务名互相访问这正是开发环境里最舒服的状态。3. 配置与实操把日常操作固化成自己的工作流3.1 Docker Desktop 设置面板里值得动的地方设置面板不是摆设装好之后有几处值得花两分钟看一眼。第一处是资源上限。Docker Desktop 默认分配的资源往往偏保守或偏激进如果你的本机内存只有 16G不限制 Docker 的资源上限容器一多整个系统都可能开始卡。我给自己定的标准是内存不超过本机总内存的四成CPU 留出至少四分之一给宿主机。这样容器能跑本机也不至于被拖死。第二处是文件共享路径。Docker Desktop 默认只共享特定目录如果你把项目放在共享目录之外容器里会访问不到。初次配置就把所有需要挂载源码的目录加进共享列表省得后面被“文件不存在”报错折磨。注意这个设置改完通常需要重启 Docker所以最好一开始就定下来。第三处是镜像存储位置。如果系统盘不够大建议把镜像文件、容器层、卷数据整体迁移到大容量磁盘。这一步同样要在用久之前完成不然数据越多迁移越麻烦。有些版本支持直接配置数据目录有些版本要从虚拟磁盘层面调整具体以你当前版本的界面为准。第四处是虚拟化后端。Windows 上主要有两种后端一种是基于 WSL 2 的一种是基于 Hyper-V 的。简单区分一下WSL 2 的文件 IO 和内存管理在很多场景下体验更好启动也快Hyper-V 后端更接近传统虚拟机对某些特殊内核依赖的兼容性更好。我自己更常推荐 WSL 2 后端但如果你有特定的内核模块依赖可能需要反过来。切换后端等于把环境重新初始化一遍选之前先想清楚。3.2 高频命令组合一条命令把状态看明白命令不在多在于组合得顺。日常用得最频繁的是下面这几条。查看所有容器状态docker ps -a-a 这个参数可以把已经退出的容器也列出来。排查问题的时候特别有用因为很多诡异现象来自“旧容器还在占着端口新容器起不来”。查看资源占用docker stats --no-stream--no-stream 是让它输出一屏后就结束而不是不停滚动刷新。需要看容器当前吃多少 CPU、内存时这一条就够。看日志docker logs -f --tail200 容器名-f 表示持续跟随--tail200 表示只显示最近 200 行。调试时这是一条保命命令先看日志再猜原因能省下大把瞎试的时间。进容器里执行命令docker exec -it 容器名 sh如果镜像精简到没有 sh只有 bash就把 sh 换成 bash有的镜像只有一个比较古怪的 shell进不去的时候先用 docker exec 容器名 which sh 探一下别硬试。早期迭代阶段我的习惯是把“停掉旧容器、删掉旧容器、用新参数启动”连在一起docker stop 容器名 docker rm 容器名 docker run ...这条组合命令省去了中间反复确认步骤的烦躁感。等到了更大一点的项目上面这套动作已经不需要手动敲了直接交给 docker compose 的 up -d --build 去处理。3.3 compose 的日常增值用法docker compose 解决的是一组容器如何统一管理的问题。我拿一个最常见的组合举例一个后端服务加一个 redis。compose 文件可以这样写version: 3.8 services: app: build: . ports: - 8000:8000 volumes: - .:/app environment: - REDIS_HOSTredis depends_on: - redis redis: image: redis:7-alpine volumes: - redis_data:/data注意我这里没有把 redis 的端口映射到宿主机因为后端服务通过服务名 redis 访问它并不需要暴露到外部。端口少暴露一个外部可访问面就少一点对本地开发来说也更干净。redis 的数据保存在命名卷 redis_data 里容器重建不影响数据。启动整套环境只需要docker compose up -d查看状态docker compose ps查看某个服务的日志docker compose logs -f app进入某个服务docker compose exec app sh收摊的时候注意 down 和 down -v 的差别。docker compose down 只删容器和默认网络卷数据留着down -v 会连命名卷一起删。一旦数据库里面有准备了很久的数据手滑敲了 -v哭都来不及。我认识的人里因为这个翻车的不是一个两个了。环境变量也建议放到 compose 文件同目录的 .env 文件里compose 会自动读取。敏感内容不要写死在 compose 文件里也不要提交到仓库本地开发的 .env 应该加入版本管理的忽略列表。4. 常见问题与排查技巧实录4.1 磁盘占用越来越大到底谁在吃空间这是 Docker Desktop 用得越久越常见的问题。第一步先看清楚占用情况docker system df它会按镜像、容器、本地卷、构建缓存四类展示占用空间。看完之后清理操作按风险从低到高来。悬空镜像就是已经被新镜像替换但仍有标签留在本地的镜像清理它们最安全docker image prune构建缓存是 Dockerfile 构建过程中留下的中间层清理不会影响正在用的镜像docker builder prune最后一档是真正的大扫除docker system prune -a --volumes这条命令会把所有没被运行的容器使用的镜像、网络、卷全部清掉。我在前一小节特意提醒过执行前确认所有需要保留的卷都已经明白列出因为它会连同未被使用的命名卷一起删除。更好的做法是每周执行一次不带 --volumes 的版本docker system prune -a我一般每周跑一次磁盘占用常年比较稳定。真正吃磁盘的大户通常是长时间迭代产生的构建缓存和旧镜像层这个命令正好对症。4.2 挂载目录后文件不同步改了代码不生效源码目录绑定挂载后容器里的进程对文件更新无感这是非 Linux 环境下比较经典的坑。原因主要有两类一类是挂载范围太宽Docker Desktop 的文件监听在大目录下会丢事件另一类是目录太深事件通知传递不完整。我的处理办法第一是缩小挂载范围。把整个项目根目录挂进去看似方便但里面通常有 .git、node_modules、构建产物之类的目录反而增加了监听负担。可以用匿名卷把这些容易出问题的路径覆盖掉比如 compose 里这样写volumes: - .:/app - /app/node_modules第二行 /app/node_modules 用了一个匿名卷让容器内这个目录不跟随宿主机映射。源码同步还在依赖目录被隔离出去热更新的稳定性提升很多。第二种原因经常出在文件共享路径的配置上。Docker Desktop 的共享目录设计是有范围的如果项目文件放在共享根目录之外同步可靠性会打折扣。把项目移动到共享范围内同时减少被监控目录层级这个问题能明显改善。这一项属于虚拟化环境下的固有限制能做的就是尽量减少文件监听面的规模。4.3 端口占用了怎么办启动容器时提示 port is already allocated太常见了。原因很简单宿主机上已经有进程占用了你指定的端口。排查思路分两步。第一步确认是谁占用了端口。Windows 上常用的命令netstat -ano | findstr :8000第二步决定改端口还是清进程。开发阶段我推荐改端口因为停掉本机服务可能会影响其他项目。把 -p 8000:8000 改成 -p 8001:8000容器内还是监听 8000宿主机访问 8001 就行。还有一类冲突是旧容器副本自己占着端口。docker ps -a 看一眼很多时候是之前启动的容器还没清掉端口一直被占着。这种情况直接 docker rm 掉旧容器再重新启动。4.4 网络相关容器访问宿主机服务和 DNS 解析问题开发场景里容器需要访问宿主机上的服务也很常见比如你本地跑了一个数据库容器里的应用要连它。Docker Desktop 在这个问题上预留了专门的主机名host.docker.internal。容器里用这个地址指向宿主机不是 127.0.0.1因为 127.0.0.1 在容器里指向容器自己。实践中我会这样用容器里的配置里数据库地址填 host.docker.internal端口填宿主机数据库的实际端口。这个机制在 Docker Desktop 的 Windows 和 Mac 版本里都有只是注意生产环境里没有这个东西写代码时需要把地址设计成可配置项。另一个经常出现的问题是容器里解析不了外部域名。表现是容器里能 ping 通 IP但用域名访问外网会提示找不到主机。这种情况基本指向 DNS 配置。本机网络切换、DNS 变动都会让容器继承到的配置失效。解决办法是修改 daemon.json给它指定一个可用的上游 DNS。在 Docker Desktop 的 Docker Engine 配置区里加入{ dns: [8.8.8.8] }保存并重启 Docker 后新启动的容器会使用这个 DNS。如果只是临时起一个容器也可以在 docker run 后面加 --dns 8.8.8.8但既然问题反复出现我更倾向于在全局配置里一次搞定。5. 我的一套收尾习惯帮你少走弯路最后分享两条我自己坚持了很久的习惯。第一条所有容器、卷、网络的命名都要有语义。容器名用“项目名加服务名”卷名能看出是哪个服务的数据网络名不要叫 default。别嫌麻烦几个月后回来看这台机器的 Docker 环境时docker ps -a 一眼就能看出每个容器是什么角色。命名混乱的环境排查问题的成本会成倍增加。第二条定期清理但不过度清理。我一般是每周跑一次 docker system prune -a把没有在用的镜像和构建缓存清掉。不带 --volumes因为我需要保留可能还会用到的数据卷。过度的清理比不清理更危险尤其是某些镜像版本不好拉回时删错了只能花时间重新折腾。Docker Desktop 用顺手的标志不是你会写几个花哨的 docker 命令而是你能把镜像、卷、网络这些基础概念组织成一套稳定的工作流。上面说的这些内容没有哪一条是高深原理但每一项都是我反复踩坑之后留下的选择。你可以先照着这套做法跑一段时间再根据项目特点调整出自己的习惯。就到这里如果读到哪一环和你的环境对不上优先看报错信息和日志原文那才是真正不会骗你的线索。
