Docker 基础体系 · 第 26/70 篇。示例以现代 Docker Engine、BuildKit 与 Compose 规范为基础，并明确 Linux 容器边界。

Docker Desktop 架构：Linux VM、文件共享、网络、资源和企业边界

Docker Desktop 不是“把 Docker Engine 安装到 macOS 或 Windows 后再加一个图形界面”。对于最常见的 Linux 容器工作流，它是在宿主操作系统上运行一个 Linux 虚拟机（Linux VM），再把 Docker Engine、containerd、BuildKit 和容器网络放进这个 Linux 环境中。宿主机上的 Docker CLI、Docker Desktop 界面、文件共享服务和端口转发服务，则负责把宿主系统与虚拟机连接起来。

这一区别决定了很多看似反直觉的行为：

macOS 和 Windows 上的容器进程并不是直接运行在宿主内核中；
bind mount 跨越了宿主机与 Linux VM 的文件系统边界；
localhost 可能分别指宿主机、虚拟机或容器；
Docker Desktop 的 CPU、内存和磁盘设置首先约束的是 Linux VM，而不是单个容器；
容器默认不是安全沙箱，Docker Engine 的控制权通常接近宿主机管理员权限；
Dev Containers、Compose、BuildKit 的配置，最终都必须适应这条宿主机—VM—容器链路。

本文中的“容器”默认指 Linux 容器。Windows 原生容器是另一套内核和镜像体系，不能把下面关于 Linux VM、Linux 内核和 Linux 文件权限的结论直接套用到 Windows 容器。

一、先建立正确的边界模型

1. Docker Desktop 包含哪些组件

可以把一次典型的 Linux 容器操作拆成以下组件：

flowchart LR
    U[开发者或 IDE] --> CLI[Docker CLI / Compose CLI]
    CLI --> API[Docker Engine API]
    API --> D[Docker daemon]
    D --> C[containerd]
    D --> B[BuildKit]
    D --> N[Linux 容器网络]
    D --> S[镜像层与卷]
    
    subgraph Host[macOS 或 Windows 宿主机]
        U
        CLI
        DP[Docker Desktop 应用]
        FS[文件共享服务]
        PF[端口转发服务]
    end

    subgraph VM[Linux VM]
        API
        D
        C
        B
        N
        S
        K[Linux kernel]
    end

    DP --> FS
    DP --> PF
    FS <--> VM
    PF <--> VM

这里有几个容易混淆的角色：

Docker CLI 是客户端。执行 docker ps 时，CLI 本身并不列出容器，它向 Docker Engine API 发送请求。

Docker daemon 是 Docker Engine 的守护进程，负责镜像、容器、网络、卷和生命周期管理。在 Docker Desktop 的 Linux 容器模式下，它通常运行在 Linux VM 内。

containerd 是容器运行时管理组件，负责镜像传输、容器生命周期等底层工作。实际创建和运行容器时，还会使用 OCI runtime，例如 runc。用户通常不直接操作这一层。

BuildKit 是现代 Docker 构建系统。它负责解析 Dockerfile、构建 LLB 图、执行构建步骤、复用缓存，并处理多阶段构建、secret mount、SSH mount 等能力。构建发生在哪里，取决于当前 Docker context 和 builder；在 Docker Desktop 的常规 Linux 容器模式下，构建工作通常在 Linux VM 中完成。

Linux VM 提供 Linux kernel、文件系统、网络栈和 cgroup 等 Linux 容器所依赖的内核能力。容器不是一个带有完整内核的虚拟机，而是一组受 Linux namespace 和 cgroup 隔离的进程。

因此，下面的关系更准确：

宿主机上的 Docker CLI
    └── 请求 Docker Engine
          └── Docker Engine 位于 Linux VM
                └── 创建 Linux 容器进程
                      └── 共享 VM 的 Linux kernel

2. Docker context 决定命令到底连接哪个 Engine

Docker CLI 可以连接不同的 Docker daemon。这个连接目标称为 context。常见检查方式是：

docker context ls
docker context show
docker info

可能看到类似结果：

NAME              DESCRIPTION                               DOCKER ENDPOINT
default           Current DOCKER_HOST based configuration   unix:///var/run/docker.sock
desktop-linux     Docker Desktop                            unix:///...

实际名称和 endpoint 会随平台、Docker Desktop 版本及配置变化，不应把某个 socket 路径写死到脚本中。关键不是名称，而是当前 CLI 指向的 Engine。

docker info 可以帮助确认边界：

docker info

需要重点观察：

Operating System；
Kernel Version；
Server Version；
Docker Root Dir；
Storage Driver；
是否启用了 BuildKit 或其他 builder。

在 macOS 或 Windows 上，即使 CLI 在宿主机运行，docker info 的服务端信息通常会显示 Linux 环境。这证明 CLI 和 daemon 不是同一个进程空间。

如果设置了 DOCKER_HOST，或者 CI 脚本切换了 context，命令可能连接远程 Engine，而不是 Docker Desktop。此时文件、网络和资源的边界都会随远程 daemon 改变。

二、为什么 Docker Desktop 需要 Linux VM

1. Linux 容器依赖 Linux kernel

Linux 容器主要依赖以下内核机制：

namespace：隔离进程、网络、挂载点、用户和主机名等视图；
cgroup：限制和统计 CPU、内存、进程数等资源；
overlay filesystem：把只读镜像层和容器可写层组合起来；
Linux 网络栈：提供 bridge、veth、iptables/nftables 等机制；
seccomp、capabilities、LSM：限制系统调用和特权能力。

macOS 使用 XNU kernel，Windows 使用 Windows NT kernel。它们不能直接充当 Linux 容器所需要的 Linux kernel。因此，在 Linux 容器模式下，Docker Desktop 必须提供一个 Linux 环境。

这不是“容器性能优化”的附加设计，而是内核兼容性的基本条件。

2. macOS 和 Windows 的实现差异

在 macOS 上，Docker Desktop 通常使用基于 Apple 虚拟化能力的 Linux VM；具体虚拟化后端和文件共享实现会随 macOS、硬件架构和 Docker Desktop 版本变化。

在 Windows 上，Docker Desktop 常见的 Linux 容器后端包括：

WSL 2 backend：利用 WSL 2 的轻量 Linux VM；
Hyper-V backend：通过 Hyper-V 运行 Linux VM。

二者都不意味着 Linux 容器直接使用 Windows kernel。WSL 2 本身也是一个 Linux kernel 环境，只是由 Windows 管理其虚拟化和集成方式。

Windows 上还存在 Windows containers 模式。Windows 容器使用 Windows 容器镜像和 Windows kernel，其进程、镜像、网络和兼容性规则与 Linux 容器不同。切换容器模式后，不能继续假定：

RUN apt-get update

或：

docker run --rm alpine uname -a

会得到 Linux 容器的行为。

3. Linux 上的 Docker Desktop 也不等于原生 Docker Engine

在 Linux 上直接安装 Docker Engine，通常是：

Linux 宿主机
  └── Linux kernel
        └── Docker Engine
              └── Linux 容器

而 Docker Desktop for Linux 的目标是提供 Desktop 产品体验和一致的开发工作流，常见架构仍可能包含由 Desktop 管理的 VM。具体行为以当前版本和发行版支持情况为准。

因此，“Linux 上 Docker 更快”不能简单归因于操作系统名称。更准确的比较是：

原生 Docker Engine：容器直接使用宿主 Linux kernel；
Docker Desktop：容器使用 Desktop 管理的 Linux VM kernel；
macOS/Windows Docker Desktop：还要跨越宿主文件系统和虚拟化边界。

三、从 Dockerfile 到容器：请求和数据如何流动

1. `docker build` 不等于在当前 shell 的操作系统上执行 Dockerfile

执行：

docker build -t demo:local .

至少包含以下步骤：

CLI 读取当前 context 和 Dockerfile；
构建请求发送给选定的 Docker Engine 或 BuildKit builder；
. 目录作为 build context 被收集并发送；
BuildKit 根据 Dockerfile 生成构建图；
每个 RUN 步骤在目标平台的构建环境中执行；
结果形成镜像层或 BuildKit 缓存；
镜像元数据和层被写入 builder 所在的存储。

在 Docker Desktop 的常规场景中，RUN apt-get ... 是在 Linux VM 提供的构建环境中执行的，不是在 macOS 的 shell 里调用 macOS 的 apt-get，也不是在 Windows 里调用 Windows 程序。

因此下面的 Dockerfile 是 Linux 镜像构建：

FROM alpine:3.20
RUN uname -a

构建并运行：

docker build -t kernel-demo .
docker run --rm kernel-demo

输出中的 kernel 信息通常反映容器所在的 Linux VM kernel，而不是宿主 macOS 或 Windows kernel。

2. Build context 是数据边界，不是“当前目录的别名”

当执行：

docker build -t app .

最后的 . 表示把当前目录作为构建输入。.dockerignore 会在发送前排除文件：

.git
node_modules
.env
dist

这不仅影响速度，也影响泄密风险。即使 Dockerfile 没有 COPY . .，敏感文件仍可能进入构建 context，尤其是在远程 builder 或构建日志、缓存管理不严谨的环境中。

现代 Dockerfile 应使用 BuildKit 的 secret mount 处理构建时凭据：

# syntax=docker/dockerfile:1

FROM alpine:3.20

RUN --mount=type=secret,id=token \
    test -s /run/secrets/token

执行：

printf '%s' 'temporary-token' > token.txt
docker build \
  --secret id=token,src=token.txt \
  -t secret-demo .
rm -f token.txt

这里的 secret 应只在 RUN 步骤的临时挂载点出现，不应写成：

ARG TOKEN
RUN curl -H "Authorization: Bearer ${TOKEN}" ...

因为 ARG 可能出现在构建历史、缓存元数据或日志中。secret mount 解决的是“不要把凭据作为普通构建输入固化到镜像层”的问题，但它不自动解决：

构建命令本身打印 secret；
第三方构建脚本把 secret 复制到输出目录；
builder 缓存中产生了敏感产物；
构建过程访问了不可信依赖源。

四、文件共享：为什么 bind mount 跨平台时会变慢或行为不同

1. 镜像文件、容器可写层、bind mount 和 named volume 不是同一种存储

容器看到的目录可能来自四个不同来源：

镜像层：构建产生的只读层；
容器可写层：容器启动后默认获得的可写层；
bind mount：把某个宿主机路径映射进容器；
named volume：由 Docker 管理的持久化卷。

例如：

docker run --rm \
  -v "$PWD:/workspace" \
  alpine:3.20 \
  sh -c 'echo hello > /workspace/result.txt'

如果当前 Docker daemon 在 Docker Desktop 的 Linux VM 中，那么 /workspace 背后的数据流大致是：

macOS/Windows 项目目录
    ⇅ Docker Desktop 文件共享层
Linux VM 中的挂载点
    ⇅ 容器 mount namespace
容器内 /workspace

容器写入 result.txt 后，Docker Desktop 必须把写操作传回宿主文件系统。这个过程不是单纯的 Linux mount --bind，而是跨虚拟机边界的文件共享。

2. named volume 为什么通常更适合数据库和依赖目录

创建并使用 named volume：

docker volume create pgdata

docker run -d \
  --name pg \
  -e POSTGRES_PASSWORD=devpass \
  -p 5432:5432 \
  -v pgdata:/var/lib/postgresql/data \
  postgres:16

pgdata 由 Docker Engine 管理，通常位于 Linux VM 的 Docker 存储中。数据库的随机读写不会为每个系统调用跨越宿主机—VM 文件共享层。

相反，下面的写法把数据库数据放在跨边界 bind mount 上：

docker run -d \
  --name pg \
  -e POSTGRES_PASSWORD=devpass \
  -p 5432:5432 \
  -v "$PWD/postgres-data:/var/lib/postgresql/data" \
  postgres:16

它的优点是宿主机可直接看到文件，缺点是：

大量小文件和随机 I/O 可能较慢；
文件锁、权限、修改时间和事件通知更容易出现平台差异；
数据库对 fsync、锁和一致性的要求更高；
删除或迁移目录时容易误操作宿主文件。

开发源代码适合 bind mount，数据库、包管理器缓存和构建缓存通常更适合 named volume。这个判断不是“卷一定更快”的规范保证，而是由跨 VM I/O 路径和工作负载特征推导出来的工程取舍。

3. Compose 中区分源码、依赖和数据

例如：

services:
  web:
    build:
      context: .
      secrets:
        - npm_token
    command: npm run dev
    ports:
      - "3000:3000"
    volumes:
      - type: bind
        source: .
        target: /workspace
      - node_modules:/workspace/node_modules
    environment:
      PORT: "3000"

  db:
    image: postgres:16
    environment:
      POSTGRES_PASSWORD: devpass
    volumes:
      - pgdata:/var/lib/postgresql/data
    ports:
      - "5432:5432"

volumes:
  node_modules:
  pgdata:

secrets:
  npm_token:
    file: ./npm-token.txt

这里有三个不同的目的：

.:/workspace：让编辑器修改的源码立即出现在容器中；
node_modules:/workspace/node_modules：避免宿主机依赖目录覆盖容器内依赖；
pgdata:/var/lib/postgresql/data：将数据库数据放在 Docker 管理的卷中。

一个常见失败是只写：

volumes:
  - .:/workspace

而镜像在构建时已经执行了：

RUN npm ci

启动容器后，宿主机的项目目录会覆盖镜像内的 /workspace，包括其中的 node_modules。如果宿主机没有同样的依赖，程序就会报告 Cannot find module。额外声明 /workspace/node_modules 的 anonymous 或 named volume，才能阻止 bind mount 覆盖该子目录。

4. 路径、权限和大小写不是跨平台透明的

路径

在 POSIX shell 中：

-v "$PWD:/workspace"

在 PowerShell 中，常用：

docker run --rm -v "${PWD}:/workspace" alpine:3.20 ls -la /workspace

更稳妥的 Compose 做法是使用相对路径：

volumes:
  - .:/workspace

但相对路径是相对于 Compose 项目目录解析的，项目目录、命令执行目录和多个 Compose 文件合并规则都可能影响最终路径。应使用：

docker compose config

检查 Compose 展开后的配置，而不是仅凭 YAML 外观判断。

权限

容器内的 UID/GID 不会因为使用 bind mount 就自动等于宿主用户。Linux 宿主机上，下面的容器进程可能以 root 身份创建文件：

docker run --rm -v "$PWD:/src" alpine:3.20 sh -c 'touch /src/from-container'

文件可能属于宿主机上的 root。可以用当前用户身份运行：

docker run --rm \
  --user "$(id -u):$(id -g)" \
  -v "$PWD:/src" \
  alpine:3.20 \
  sh -c 'touch /src/from-container'

但这要求镜像中的进程在该 UID 下确实能够运行，并且某些程序需要可写的 home、临时目录或缓存目录。macOS 和 Windows 的 Desktop 文件共享层通常不会完整暴露 Linux 宿主机那样的 UID/GID 语义，因此同一命令在不同平台上可能表现不同。

大小写和文件事件

macOS 默认文件系统通常大小写不敏感，Windows 文件系统也常见大小写不敏感，而 Linux 容器内通常按大小写敏感处理。项目中同时存在 Config.js 和 config.js 时，宿主机和容器可能得到不同结果。

前端开发工具、测试运行器和 Dev Containers 依赖文件事件通知。跨 VM 文件共享可能导致：

修改后容器内不能及时收到事件；
工具退化为轮询；
大型项目热重载变慢；
原子重命名和锁行为与原生 Linux 不同。

这不是 Node、Python 或编辑器单方面的 bug，而是文件事件必须穿越共享层的结果。需要高频读写的目录应尽量放入 Linux VM 内的 named volume，或者使用专门的文件同步工具；但同步工具会引入新的冲突解决和一致性问题，不能把它当成无成本加速。

五、网络：三个 `localhost` 和一条端口转发链路

1. Linux 容器默认使用隔离的 network namespace

Docker 默认创建一个 bridge 网络。一个简化的 Linux 容器网络结构是：

flowchart LR
    H[宿主机应用] --> P[Docker Desktop 端口转发]
    P --> V[Linux VM 网络栈]
    V --> B[docker bridge]
    B --> C1[web 容器 eth0]
    B --> C2[db 容器 eth0]
    C1 --> C2

容器内部通常有独立的网络 namespace 和 eth0。容器通过虚拟网卡连接到 bridge，Docker Engine 为其分配 IP，并设置 NAT、转发和 DNS。

Compose 服务之间通信时，应使用服务名：

services:
  web:
    image: nginx:alpine
    depends_on:
      - api
  api:
    image: alpine:3.20
    command: sh -c "while true; do nc -l -p 8080 -e sh -c 'printf HTTP/1.1\\ 200\\ OK\\\\r\\\\n\\\\r\\\\napi'; done"

web 访问 api:8080，而不是访问 localhost:8080。Compose 会在项目网络中提供服务名解析。localhost 在 web 容器内表示 web 容器自己，不表示 api，也不表示宿主机。

2. 发布端口是“宿主机端口到容器端口”的映射

运行：

docker run -d \
  --name web \
  -p 8080:80 \
  nginx:alpine

-p 8080:80 的含义是：

宿主机可访问的 8080
    → Docker Desktop 端口转发
      → Linux VM 中的 Docker 网络
        → web 容器的 80

它不表示容器直接拥有宿主机的 8080，也不表示容器内服务自动监听了所有外部接口。

验证：

curl http://localhost:8080
docker port web

预期可以看到 Nginx 响应以及类似：

80/tcp -> 0.0.0.0:8080

如果应用只监听 127.0.0.1，即使发布了端口，也可能无法从其他容器或端口转发路径访问。容器内服务通常应监听：

0.0.0.0:<port>

而不是：

127.0.0.1:<port>

3. 宿主机、VM 和容器的 `localhost` 不同

下面三个地址可能指三个不同对象：

执行位置	`localhost` 指向
宿主机浏览器	宿主机网络命名空间
Linux VM 中的进程	Linux VM 自身
容器中的进程	当前容器自身

因此，在容器内访问宿主机上运行的服务，不能默认使用 localhost。Docker Desktop 通常提供：

host.docker.internal

例如：

docker run --rm alpine:3.20 \
  wget -qO- http://host.docker.internal:8000

前提是宿主机确实在端口 8000 提供 HTTP 服务，并且宿主机防火墙和 Docker Desktop 设置允许该访问。

反方向，宿主机访问容器服务，通常使用发布端口：

http://localhost:8080

而不是使用容器 IP。容器 IP 属于 Docker 内部网络，Desktop 平台上不应假设宿主机可以像原生 Linux 那样直接路由到它。

host.docker.internal 是 Docker Desktop 提供的开发便利名称，不是 Compose 服务发现机制。容器间通信应使用服务名；容器访问宿主机才考虑该名称。

4. 端口发布冲突和“服务启动但访问失败”

以下命令可能失败：

docker run -d --name a -p 8080:80 nginx:alpine
docker run -d --name b -p 8080:80 nginx:alpine

第二个容器通常会因为宿主机的 8080 已被占用而启动失败或无法完成端口绑定。解决方法是改宿主端口：

docker run -d --name b -p 8081:80 nginx:alpine

诊断顺序可以是：

docker ps
docker ps -a
docker logs b
docker port b
curl -v http://localhost:8081

如果容器已运行但端口访问失败，还应检查应用实际监听地址：

docker exec b ss -lntp

有些最小镜像没有 ss，可以进入容器检查配置，或临时使用带诊断工具的镜像。docker ps 只能说明容器进程还在，不等于应用端口已经就绪。

5. “端口已发布”不等于“服务已就绪”

Compose 的 depends_on 默认主要表达启动顺序，不等于应用健康检查完成。数据库进程已经创建但尚未接受连接时，应用仍可能启动失败。

可以增加健康检查：

services:
  db:
    image: postgres:16
    environment:
      POSTGRES_PASSWORD: devpass
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 5s
      timeout: 3s
      retries: 20

  app:
    image: my-app:dev
    depends_on:
      db:
        condition: service_healthy

这只能减少启动竞态，不能取代应用自身的重试和断线恢复。网络、VM 重启、数据库恢复和连接池耗尽都可能在启动后发生。

六、资源：Docker Desktop 的限制对象到底是谁

1. 资源层次不是只有一个 `--memory`

Linux 容器资源大致处于以下层次：

宿主机硬件资源
    └── Docker Desktop Linux VM 配额
          └── Docker daemon / BuildKit / 容器共享的 VM 资源
                └── 单个容器的 cgroup 限制

Docker Desktop 的 CPU、内存、交换空间和磁盘设置，首先决定 Linux VM 可以使用多少资源。单个容器的参数则进一步设置 cgroup 限制：

docker run --rm \
  --memory=512m \
  --cpus=1.5 \
  alpine:3.20 \
  sh -c 'cat /sys/fs/cgroup/memory.max; cat /sys/fs/cgroup/cpu.max'

具体输出格式随 cgroup 版本和镜像环境变化，但含义是：

--memory=512m 限制该容器的内存上限；
--cpus=1.5 允许大约 1.5 个 CPU 的计算配额；
容器不能突破 VM 可获得的整体资源。

如果 VM 只配置了 2 GB 内存，给四个容器各设置 --memory=1g 并不会创造 4 GB 物理内存。实际竞争发生在 VM 内，可能导致回收、交换、OOM 或宿主机压力。

2. 构建也会消耗 Desktop 资源

下面这些操作都可能消耗 Linux VM 的 CPU、内存和磁盘：

BuildKit 并行执行多个 RUN；
编译器和链接器占用大量内存；
镜像层和构建缓存持续增长；
容器日志增长；
named volume 保存数据库和依赖；
WSL 2 中其他发行版或服务共同运行。

检查镜像、容器和卷：

docker system df
docker system df -v
docker ps -s

清理时必须区分对象：

docker image prune
docker builder prune
docker container prune
docker volume prune

docker system prune 的影响更广，可能删除未使用的容器、网络、镜像和构建缓存。--volumes 会进一步涉及卷，数据库数据可能因此丢失。清理前应确认：

docker volume ls
docker inspect <volume-name>

磁盘空间不足时，问题未必来自正在运行的容器，也可能来自镜像层、BuildKit cache、容器日志或 Docker Desktop 的虚拟磁盘文件。删除宿主机上看起来像 Docker 数据的内部文件不是安全清理方式，应通过 Docker 命令和 Desktop 提供的磁盘管理功能操作。

3. WSL 2 的内存观察可能与直觉不同

Windows 的 WSL 2 backend 使用轻量虚拟机。其内存由 WSL 和 Docker Desktop 共同管理，宿主机任务管理器、WSL 内部工具和容器 cgroup 看到的数字不一定相同。

因此诊断内存问题时要分层：

docker stats
docker events
docker inspect <container>
docker info

docker stats 观察容器维度；
docker inspect 检查容器配置；
docker info 观察 Engine 和存储概况；
Desktop/WSL/宿主机工具观察 VM 和宿主机维度。

如果容器没有设置内存限制，容器通常受 VM 和系统整体资源约束，而不是自动获得一个固定的小额度。若容器被 OOM kill，日志中可能只留下进程退出、137 等表现；还需结合宿主机和 VM 的内存压力判断，不能仅凭退出码断言唯一原因。

4. 资源限制与 CPU 架构是两类问题

Apple Silicon 或 ARM Windows 设备上，镜像平台可能是 linux/arm64；很多服务器镜像仍主要提供 linux/amd64。检查镜像平台：

docker image inspect nginx:alpine \
  --format '{{.Os}}/{{.Architecture}}'

构建多平台镜像：

docker buildx build \
  --platform linux/amd64,linux/arm64 \
  -t registry.example.com/demo/app:1.0 \
  --push .

--platform linux/amd64 可能触发 QEMU 模拟。它解决的是指令集兼容性，不等于性能与原生架构相同。数据库、编译和大量系统调用在模拟下可能明显变慢；生产部署前应在目标架构上验证。

七、容器不是虚拟机：Linux VM 才是 Desktop 的主要内核边界

容器通过 namespace、cgroup、capabilities 和 seccomp 等机制隔离进程，但共享 Linux kernel。一个获得过多权限的容器，可能影响同一 Linux VM 中的其他容器，甚至进一步影响 Desktop 环境。

例如：

docker run --rm -it \
  --privileged \
  alpine:3.20 \
  sh

--privileged 会显著放宽设备、capability 和安全限制。它不是“让程序更容易运行”的普通兼容开关，而是在扩大内核操作权限。类似风险还包括：

-v /var/run/docker.sock:/var/run/docker.sock

挂载 Docker socket 后，容器内程序通常可以调用 Docker Engine API 创建其他容器、挂载宿主路径或获取更多权限。虽然它没有直接等同于“挂载宿主机 root 文件系统”，但在默认 Docker Engine 权限模型下，拥有该 socket 往往接近拥有 Engine 管理权限。

因此下面的 Dev Container 配置有明显边界风险：

{
  "mounts": [
    "source=/var/run/docker.sock,target=/var/run/docker.sock,type=bind"
  ]
}

它常用于 Docker-in-Docker 的替代方案，即让开发容器调用外部 Engine。但应明确：

该容器内的开发工具可能控制整个 Docker Desktop Engine；
项目依赖、脚本和扩展如果不可信，可能利用 socket；
这不是严格的容器安全隔离；
更强隔离需要独立 Engine、远程 builder、受控 CI 或 Desktop 的增强隔离能力。

Docker-in-Docker 与 Docker-outside-of-Docker 也不同：

Docker-outside-of-Docker：容器挂载外部 Docker socket，容器内 CLI 控制宿主 Engine；
Docker-in-Docker：容器内运行另一个 daemon，通常需要特权或特殊运行时；
远程 Docker Engine：CLI 或开发工具连接单独的受控 daemon。

选择哪种方式取决于是否需要隔离 daemon、是否需要缓存共享以及企业安全边界，不能只按“能不能构建镜像”判断。

八、企业边界：技术隔离、数据边界和产品授权不是一件事

1. Docker Desktop 的技术边界

Docker Desktop 同时接触以下高价值对象：

宿主机上被共享的源代码和文件；
容器中的环境变量、配置和凭据；
镜像 registry 的登录凭据；
Docker Engine API；
构建缓存和镜像层；
代理、VPN 和企业网络；
Linux VM 的磁盘镜像。

所以“容器不能直接访问宿主机”是不准确的。更准确的说法是：

容器默认只能看到自己的文件系统和被授予的资源；但 Docker Desktop 为 bind mount、端口转发和 Engine API 提供了跨边界通道，而这些通道可能扩大访问范围。

文件共享权限、容器权限和企业终端控制应分别评估。只允许共享项目目录，比共享整个用户目录更容易审计；只给容器必要 capability，比使用 --privileged 更容易控制。

2. Enhanced Container Isolation 的位置

Docker Desktop 的某些版本和订阅能力提供 Enhanced Container Isolation（增强容器隔离）等安全功能，用于强化容器与 Docker Desktop Linux VM、Engine 管理面的隔离。具体支持平台、版本、策略和限制应以当前 Docker Desktop 文档为准。

这类能力不能被理解为：

容器自动变成不受信任代码沙箱；
bind mount 失去宿主文件访问风险；
Docker socket 自动变安全；
应用漏洞和供应链风险自动消失。

如果开发者主动授予容器宿主文件、Docker socket、设备或特权能力，任何增强隔离方案的安全收益都可能被削弱。企业策略仍需要限制：

哪些目录允许共享；
是否允许 privileged 容器；
是否允许 Docker socket；
能访问哪些 registry；
构建是否允许外网；
secret 是否进入开发容器；
终端和 VM 磁盘是否加密、备份和审计。

3. 产品授权边界

Docker Engine 技术上可以按开源组件和商业组件组合使用，但 Docker Desktop 是带有独立订阅和许可条件的产品。企业是否需要付费订阅、哪些组织规模或使用场景受限，会随 Docker 的当前政策变化。

因此，以下两类问题必须分开：

“这个容器能否运行？”
    → 技术兼容性和权限问题

“这个组织能否这样使用 Docker Desktop？”
    → 产品许可、组织规模和合同政策问题

不能因为命令在个人电脑上成功执行，就推断企业使用已经符合许可或安全要求。企业应以 Docker 当前官方条款、订阅说明和内部采购政策为准。

九、一个完整的跨平台开发算例

下面构造一个最小的 Web + PostgreSQL 开发环境，展示文件、网络、卷、构建 secret 和资源边界。

1. 项目文件

Dockerfile：

# syntax=docker/dockerfile:1

FROM node:22-bookworm-slim

WORKDIR /workspace

COPY package*.json ./

RUN --mount=type=cache,target=/root/.npm \
    --mount=type=secret,id=npm_token,required=false \
    npm ci

COPY . .

EXPOSE 3000

CMD ["npm", "run", "dev", "--", "--host", "0.0.0.0"]

compose.yaml：

services:
  web:
    build:
      context: .
      secrets:
        - npm_token
    command: npm run dev -- --host 0.0.0.0
    ports:
      - "3000:3000"
    volumes:
      - type: bind
        source: .
        target: /workspace
      - node_modules:/workspace/node_modules
      - npm_cache:/root/.npm
    environment:
      DATABASE_URL: postgres://postgres:devpass@db:5432/app
    depends_on:
      db:
        condition: service_healthy
    cpus: 1.5
    mem_limit: 1g

  db:
    image: postgres:16
    environment:
      POSTGRES_DB: app
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: devpass
    volumes:
      - pgdata:/var/lib/postgresql/data
    ports:
      - "5432:5432"
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres -d app"]
      interval: 5s
      timeout: 3s
      retries: 20

volumes:
  node_modules:
  npm_cache:
  pgdata:

secrets:
  npm_token:
    file: ./npm-token.txt

这个配置中的关键因果关系如下：

context: . 决定源码和 Dockerfile 的构建输入；
npm_cache 将 npm 缓存放到 Docker 管理的卷，减少跨 VM bind mount I/O；
.:/workspace 让源码修改立即出现在容器；
/workspace/node_modules 单独使用卷，避免源码 bind mount 覆盖依赖；
db 使用 pgdata，避免数据库随机 I/O 直接穿越文件共享层；
web 连接数据库时使用 db:5432，因为 db 是 Compose 网络中的服务名；
宿主浏览器访问 Web 时使用 localhost:3000，因为 3000:3000 发布了端口；
应用监听 0.0.0.0，使端口转发和其他容器能够访问它；
mem_limit 和 cpus 约束的是 web 容器，但仍受 Docker Desktop VM 总资源约束；
npm_token 只作为 BuildKit secret 传递，不应写进 Dockerfile 的 ARG 或普通环境变量。

启动前先展开配置：

docker compose config

检查：

bind mount 的目标路径；
端口是否符合预期；
healthcheck 和 depends_on 是否被正确解析；
secret 文件路径是否存在。

启动：

docker compose up --build

验证：

docker compose ps
docker compose logs web
docker compose exec web getent hosts db
curl http://localhost:3000

getent hosts db 应能解析到 Compose 网络中的数据库地址。curl http://localhost:3000 则是在宿主机执行，走的是宿主机端口到容器端口的转发路径。

停止服务：

docker compose down

这通常会删除容器和 Compose 创建的网络，但不会删除 named volumes。若执行：

docker compose down -v

则会删除 pgdata、node_modules 和 npm_cache 等 Compose 管理的卷，数据库数据也会随之删除。这个命令不能作为普通的“重启”命令使用。

2. 为什么 Dev Container 会继承这些边界

Dev Containers 通常只是把编辑器、终端和调试器连接到一个开发容器中，并不会改变 Docker Desktop 的底层边界：

IDE
  → Docker CLI / Engine API
    → Docker Desktop Linux VM
      → Dev Container
        → bind mount 源码
        → named volume 依赖
        → Compose 服务网络

devcontainer.json 中的：

mounts 会影响文件边界；
features 会影响镜像构建步骤；
runArgs 可能增加 capability、端口或资源配置；
remoteEnv 和 containerEnv 会影响运行时环境；
mounts 到 Docker socket 会扩大 Engine 控制范围；
BuildKit cache mount 会影响构建速度和磁盘占用。

因此 Dev Container 的“可复现”不只是锁定一个基础镜像。还需要明确：

基础镜像平台；
Feature 版本；
Compose 服务和网络；
源码挂载路径；
UID/GID 行为；
依赖缓存的位置；
secret 的传入方式；
Docker Desktop VM 和 Engine 的版本差异。

十、故障诊断：先确定是哪一层坏了

遇到“容器运行不正常”时，可以按边界逐层排查。

1. CLI 是否连接到正确的 daemon

docker context show
docker info

如果 context 指向远程 Engine，那么你看到的镜像、容器、卷和网络都不属于当前 Desktop VM。

2. 容器进程是否存活

docker ps
docker ps -a
docker inspect <container>
docker logs <container>

docker ps 为空不代表 Docker Desktop 故障，也可能是容器已经退出。docker ps -a 才能看到退出状态。

3. 应用是否监听正确端口和地址

docker exec <container> sh

进入后检查应用配置。若工具存在：

ss -lntp

要确认：

监听端口是否正确；
是否绑定 0.0.0.0；
应用是否启动后立即退出；
配置中的数据库主机是否写成了错误的 localhost。

4. 网络名称解析和服务连通性

docker compose exec web getent hosts db
docker compose exec web sh

在 web 容器内访问：

db:5432

而不是：

localhost:5432

如果宿主机访问 localhost:5432 失败，则检查数据库服务是否发布了端口、宿主端口是否冲突，以及数据库是否已经通过 healthcheck。

5. 文件是否来自预期来源

docker inspect <container>
docker compose config
docker compose exec web sh -c 'pwd; ls -la /workspace; ls -la /workspace/node_modules'

重点判断：

bind mount 是否覆盖了镜像内目录；
named volume 是否挂载到正确路径；
Compose 相对路径是否解析到正确项目目录；
容器内生成的文件是否出现在宿主机；
文件权限和大小写是否造成应用错误。

6. 是资源耗尽还是应用错误

docker stats
docker system df
docker events

如果构建缓慢，可能是：

源码位于跨 VM bind mount，导致大量小文件读写；
BuildKit 缓存未命中；
VM CPU 或内存不足；
使用了不同架构的模拟；
registry 或代理网络延迟。

如果容器被杀死，检查内存限制、Desktop VM 资源和宿主机压力，不能只增加容器的 --memory。容器上限高于 VM 可用内存时，问题仍然存在。

十一、常见误解与真实边界

误解一：容器共享宿主机 kernel，所以 macOS 可以直接运行 Linux 容器

不正确。Linux 容器共享的是 Linux VM 的 kernel。macOS 和 Windows 只是提供了宿主机、虚拟化和集成功能。

误解二：`localhost` 总是代表我的电脑

不正确。程序运行在哪个网络 namespace，localhost 就指向哪个 namespace。宿主机、VM 和容器可能各自有自己的 localhost。

误解三：bind mount 就是普通目录映射

在原生 Linux Engine 上，bind mount 通常更接近内核级路径挂载；在 Docker Desktop 上，它往往还要经过宿主机与 Linux VM 之间的文件共享层。因此性能、事件、权限、锁和大小写行为可能不同。

误解四：named volume 一定能在宿主机文件管理器中直接找到

named volume 的数据通常由 Docker Engine 存储在 Linux VM 内部。宿主机文件管理器看不到一个等价的普通项目目录。应使用 Docker 卷命令、数据库备份或容器内工具访问数据，不要直接修改 Desktop 的内部磁盘文件。

误解五：容器隔离后，项目脚本就可以完全不信任

不正确。挂载 Docker socket、宿主目录、设备或使用 --privileged 都可能扩大权限。容器隔离是配置结果，不是绝对安全承诺。

误解六：Docker Desktop 的内存设置就是每个容器的内存

不正确。Desktop 设置约束 Linux VM；容器 cgroup 参数约束单个容器。构建器、缓存、日志、数据库和其他容器共同消耗 VM 资源。

误解七：开发机能运行就能在生产运行

不正确。Docker Desktop 的 Linux VM、文件共享、端口转发、宿主机集成和凭据存储是开发环境能力。生产环境通常直接使用 Linux 主机上的 Docker Engine、容器平台或编排系统，文件、网络、存储类和安全策略都需要重新验证。

十二、最终的判断框架

分析 Docker Desktop 问题时，不要先问“Docker 为什么和 Linux 不一样”，而应先定位对象：

命令连接的是哪个 Docker daemon？
    ↓
daemon 位于哪个 Linux VM 或远程主机？
    ↓
文件是镜像层、可写层、bind mount 还是 named volume？
    ↓
网络访问发生在宿主机、VM 还是容器 namespace？
    ↓
资源限制施加在 Desktop VM、builder 还是单个容器？
    ↓
是否通过 socket、privileged、设备或宿主目录扩大了安全边界？

在 macOS 和 Windows 上运行 Linux 容器时，最重要的事实是：Docker Desktop 为 Linux 容器提供了一个 Linux 执行环境，并通过文件共享、网络转发和资源管理把它接入宿主机。

文件访问慢，通常要看是否跨越共享层；容器访问不到数据库，通常要先检查服务名和网络 namespace；内存不足，通常要区分 VM 配额和容器 cgroup；企业风险，则要检查 bind mount、Docker socket、特权参数、镜像来源和组织策略。

一旦把这些边界分开，Docker Desktop 就不再是一个隐藏细节很多的黑盒，而是一条可以逐段验证的链路：宿主机负责用户界面与集成，Linux VM 提供 Linux kernel 和 Engine，BuildKit 负责构建，容器 namespace 提供进程视图，Docker 网络负责连接，卷和共享层负责数据路径，而权限配置决定这条链路最终能跨越多远。

系列导航与关联阅读

系列入口：Docker 完整学习路线：从镜像与容器到安全、可观测和生产交付
上一篇：Rootless Docker：User Namespace、网络、存储、限制和迁移
下一篇：Dev Containers 开发环境：配置、Feature、缓存、Secret 和复现
延伸：Docker 在 Linux、macOS 与 Windows 的差异：VM、路径、网络和性能

官方资料

本文依据 Docker、OCI 与 CNCF 官方文档重新梳理；正文与生产检查清单由 WR BLOG 编写。