Docker Desktop：把桌面虚拟化、容器运行时与开发环境管成一套基线
上午还能启动的项目，下午突然报出 Cannot connect to the Docker daemon。有人重装 Docker，有人删除 volume，还有人发现 Windows Terminal 与 WSL 中列出的容器完全不同。真正需要先回答的不是“Docker 坏没坏”，而是三个更具体的问题：Docker Desktop 进程是否健康，当前 CLI 通过哪个 context 连接哪个 daemon，项目数据究竟位于哪套受管虚拟磁盘。
Docker Desktop 不是给 Docker Engine 加一层界面。Windows 和 macOS 不能直接用 Linux 内核的 namespace、cgroup 与 overlay 文件系统运行 Linux 容器，Desktop 因而管理一个 Linux 环境，再把 Docker API、文件共享、端口转发、凭证存储和代理配置接回宿主机。理解这条链路，才能区分应用故障、容器故障、daemon 故障与虚拟化后端故障。
先画清 CLI 到容器的真实路径
docker 是客户端，Desktop 管理的 daemon 才创建容器。docker context show 决定客户端当前连到哪里；docker version 同时出现 Client 和 Server 才证明 API 链路完整；docker info 才能回答操作系统、存储后端、CPU、内存、代理与日志驱动等运行事实。
先保留一份无敏感信息的诊断快照：
docker context ls
docker context show
docker version
docker info --format 'os={{.OperatingSystem}} cpus={{.NCPU}} memory={{.MemTotal}} driver={{.Driver}} logging={{.LoggingDriver}}'预期当前 context 是 desktop-linux，版本输出包含 Server，操作系统能识别为 Docker Desktop 管理的 Linux 环境。只有 Client、Server 区域报连接错误，说明 CLI 已安装但 daemon 链路未建立。不要在此时删除 volume，那不会修复连接，反而可能把仍可恢复的数据一起删掉。
Windows：先选后端，再安装 Desktop
Windows 开发团队通常优先采用 WSL 2 后端。它适合 Linux 容器、Linux 工具链和把源码放在 WSL 文件系统中的开发方式。Hyper-V 后端适合已经围绕 Hyper-V 管理隔离边界、需要对应企业策略，或不能使用 WSL 集成的环境。两者都依赖硬件虚拟化；在 VDI 或虚拟机里还要由外层平台提供嵌套虚拟化，不能只在 Windows 功能面板勾选选项。
先在 PowerShell 检查环境：
Get-ComputerInfo -Property WindowsProductName,WindowsVersion,OsBuildNumber,HyperVisorPresent
wsl.exe --version
wsl.exe --status
wsl.exe -l -vWSL 发行版的 VERSION 应为 2。如果 wsl --version 不输出版本详情，先更新 WSL；如果 BIOS/UEFI 未启用虚拟化，Desktop 可能停在 Starting，WSL 也无法创建二代虚拟环境。团队部署前应在设备清单里验证操作系统仍处于厂商支持周期、CPU 架构、可用内存和虚拟化策略，而不是把某次安装成功的最低值写成永久标准。
安装包从 Docker 官方下载入口或企业批准的软件分发系统取得。交互安装适合个人设备；批量部署应固定已审查版本，保存安装包摘要和回退包。当前 Windows 安装还要选择权限模型：
每用户安装目前仍是 Beta，进入当前用户目录，只支持 WSL 2 后端，不需要管理员权限完成 Desktop 自身的安装与更新；首次启用 WSL 2 仍可能需要一次机器级提权。它不安装特权系统服务，宿主机攻击面相对较小。全用户安装进入系统目录，可选 WSL 2 或 Hyper-V；Windows containers 还要求受支持的 Windows Pro/Enterprise 版本，需要管理员完成安装，并可能运行特权服务。Windows Home 与 Education 只运行 Linux containers。
每用户安装示例：
$installer = Join-Path $PWD 'Docker Desktop Installer.exe'
if (-not (Test-Path -LiteralPath $installer)) { throw 'installer not found' }
Start-Process $installer -Wait -ArgumentList 'install','--user','--backend=wsl-2'全用户安装必须在提升权限的终端执行：
$installer = Join-Path $PWD 'Docker Desktop Installer.exe'
if (-not (Test-Path -LiteralPath $installer)) { throw 'installer not found' }
Start-Process $installer -Wait -ArgumentList 'install','--backend=wsl-2'安装完成后启动 Docker Desktop，接受组织已审查的订阅条款，再检查 docker version。不要把用户随手加入 docker-users 当成通用修复。该组用于需要访问特权服务的能力，权限接近宿主机管理员；WSL 2 Linux 容器的普通使用并不天然要求它。
WSL 集成只保留一条主路径
进入 Settings -> General 确认 WSL 2 engine，再到 Settings -> Resources -> WSL Integration 只启用实际开发所用的发行版。随后在 PowerShell 和该发行版里分别执行：
docker context show
docker version --format 'client={{.Client.Version}} server={{.Server.Version}}'
docker info --format 'name={{.Name}} os={{.OperatingSystem}}'两边应指向同一 Desktop daemon，并看到同一组测试容器。不要在已集成的 WSL 发行版里再安装并启动一套 docker-ce，否则 PATH、DOCKER_HOST、systemd socket 和 Desktop context 可能互相覆盖。出现“两边容器不同”时，依次检查：
command -v docker
docker context ls
printf 'DOCKER_HOST=%s\n' "${DOCKER_HOST:-<unset>}"
docker info --format '{{.Name}}|{{.DockerRootDir}}'DOCKER_HOST 会覆盖当前 context。排障时先暂时取消它并重新验证，不要直接删除 context：
unset DOCKER_HOST
docker context use desktop-linux
docker version大型源码仓库应放在 WSL 的 Linux 文件系统，例如 ~/src/project，再通过 IDE 的 WSL 入口打开。把 node_modules、Git 工作树和大量小文件跨挂载到 /mnt/c，通常会增加元数据开销、权限差异和大小写问题。团队应记录两种位置的冷构建时间、热构建时间和文件监听延迟，用测量结果决定基线。
macOS：CPU 架构、虚拟化与权限要一起判断
macOS 安装包需要匹配 Apple silicon 或 Intel。先检查：
uname -m
sw_vers
sysctl -n machdep.cpu.brand_string 2>/dev/null || true从官方入口下载对应 .dmg，校验发布说明给出的摘要后拖入 Applications。设备批量部署优先使用官方 PKG；单机命令行安装可以在保持安装卷挂载期间执行：
set -eu
test -f ./Docker.dmg
sudo hdiutil attach ./Docker.dmg
trap 'sudo hdiutil detach /Volumes/Docker >/dev/null 2>&1 || true' EXIT
sudo /Volumes/Docker/Docker.app/Contents/MacOS/install --user="$USER"--user 会在安装阶段完成符号链接和 localhost 等需要提权的配置，减少首次启动提示，但也把 Desktop 限定给指定的单个 macOS 账户。企业仍应由设备管理系统控制安装包、首次授权和升级窗口。Apple silicon 上运行只提供 amd64 变体的镜像会发生模拟，功能可能可用，但构建时长和 CPU 成本会明显上升；团队镜像基线应发布目标架构或多架构 manifest。
首次启动后执行：
docker version
docker context show
docker info --format 'arch={{.Architecture}} cpus={{.NCPU}} memory={{.MemTotal}}'
platform="$(uname -m | sed 's/x86_64/amd64/;s/arm64/arm64/')"
docker run --rm --platform "linux/$platform" alpine uname -mamd64 容器通常输出 x86_64，arm64 容器通常输出 aarch64。若出现 no matching manifest，先确认镜像是否发布目标架构；若强制 linux/amd64 后能运行但明显变慢，证据指向模拟成本，不应通过无限增加 Desktop CPU 掩盖镜像缺口。
用自包含实验验证端口、挂载与 context
下面的实验只创建带唯一标签的容器和临时目录，不触碰其他项目。镜像引用应在团队环境替换为已审查摘要；首次学习可以使用目标版本标签并记录最终 digest。
set -eu
lab="desktop-lab-$(date +%s)"
work="${TMPDIR:-/tmp}/$lab"
expected_context=desktop-linux
cleanup() {
actual_label="$(docker inspect "$lab" --format '{{ index .Config.Labels "tool-efficiency.lab" }}' 2>/dev/null || true)"
if [ "$actual_label" = "$lab" ]; then
docker rm -f "$lab" >/dev/null
fi
case "$work" in
"${TMPDIR:-/tmp}"/desktop-lab-*) rm -rf -- "$work" ;;
*) printf 'refuse unsafe cleanup: %s\n' "$work" >&2; return 23 ;;
esac
}
trap cleanup EXIT
test -z "${DOCKER_HOST:-}"
test "$(docker context show)" = "$expected_context"
mkdir -p "$work"
printf 'DESKTOP_OK\n' > "$work/index.html"
docker run -d --name "$lab" \
--label tool-efficiency.lab="$lab" \
--memory 128m --cpus 0.50 \
-p 127.0.0.1::80 \
--mount "type=bind,src=$work,dst=/usr/share/nginx/html,readonly" \
nginx:alpine
host_port="$(docker port "$lab" 80/tcp | awk -F: '{print $NF}')"
body=''
for attempt in $(seq 1 20); do
body="$(curl -fsS "http://127.0.0.1:$host_port/" 2>/dev/null || true)"
[ "$body" = 'DESKTOP_OK' ] && break
sleep 1
done
test "$body" = 'DESKTOP_OK'
limits="$(docker inspect "$lab" --format 'memory={{.HostConfig.Memory}} nano_cpus={{.HostConfig.NanoCpus}}')"
test "$limits" = 'memory=134217728 nano_cpus=500000000'
printf 'VERIFY_OK context=%s port=%s %s\n' "$expected_context" "$host_port" "$limits"预期退出码为 0，输出包含 VERIFY_OK，内存值为 134217728，CPU 配额为 500000000。这同时证明镜像拉取、daemon API、端口转发、文件共享和资源字段生效。
反向实验把挂载目录改成不存在或未授权共享的位置：
set +e
docker run --rm --mount type=bind,src=/path/that/does/not/exist,dst=/data alpine test -d /data
rc=$?
set -e
test "$rc" -ne 0
printf 'EXPECTED_FAILURE rc=%s\n' "$rc"预期 Docker 在创建容器阶段返回非零退出码，并留下 bind source path does not exist 或文件共享权限相关证据。若命令意外成功，先确认该路径是否真的不存在，以及 CLI 是否切到了另一个 daemon。
正向实验用 trap 收口，退出时只删除标签与随机名称一致的容器，并用临时目录前缀阻止越界删除。即使命令在端口探针阶段失败，也不会把未标记对象或其他项目目录带入清理。
不要把 docker system prune -a --volumes 放进项目重置脚本。它按 daemon 全局清理，可能删除其他项目仍要使用的镜像、网络、缓存和数据卷。
资源配置改变的是整台开发机的竞争关系
Docker Desktop 的 CPU、内存、swap 和磁盘限制约束受管 Linux 环境，不等于单容器限额。Windows WSL 2 后端的资源还受 WSL 全局策略影响；macOS 与 Hyper-V 后端可在 Desktop Resources 中直接分配。先观察，再调大：
docker info --format 'cpus={{.NCPU}} memory={{.MemTotal}} root={{.DockerRootDir}}'
docker stats --no-stream
docker system df -v一个常见误判是构建结束后宿主机内存没有立刻下降，于是持续给 Desktop 增配。WSL 可能保留页缓存，磁盘镜像也不会因为删镜像立即缩小。判断容量时同时看宿主机压力、WSL/VM 内存、容器工作集、镜像与 Build Cache 增长。资源基线至少保留：
日常 IDE、浏览器和容器同时运行时的宿主机剩余内存。冷构建与热构建的峰值 CPU、内存、耗时和磁盘增长。项目依赖全部启动后的稳态资源与端口占用。
清理 Build Cache 前后的可回收空间，以及下次构建的回源代价。
调得太小会出现构建进程被 OOM kill、Kubernetes 组件反复重启和 IDE 卡顿；调得太大则会让宿主机交换、风扇持续高负载，甚至挤压安全软件和视频会议。单容器资源仍应在 docker run 或 Compose 中声明，避免一个失控任务吃掉 Desktop 的全部额度。
代理与企业 CA 要按流量方向拆开
Desktop 自身登录、扩展和部分 CLI 流量，daemon 拉取镜像，构建阶段下载依赖，运行中容器访问外网，并不是同一条网络路径。企业代理环境至少做四个探针：
docker pull alpine
docker run --rm alpine wget -qO- https://example.com >/dev/null
printf 'FROM alpine\nRUN wget -qO- https://example.com >/dev/null\n' | docker build --no-cache -t desktop-proxy-probe -
docker image rm desktop-proxy-probe第一条失败而宿主机浏览器正常，优先检查 Desktop 的 Containers proxy、PAC 返回值、registry 域名旁路和代理认证。第一条成功、容器内失败，检查运行时环境变量与容器信任库。构建失败而运行容器成功，检查 BuildKit 的代理参数和构建网络。
不要把代理密码写进 Dockerfile、镜像标签、Git 仓库或可共享的 config.json。也不要照搬 Linux Engine 教程把代理写进 Desktop 的 daemon.json，Docker Desktop 会忽略那里的 daemon 代理配置，应使用 Desktop 的 Proxies 设置或组织管理策略。Desktop 支持的代理认证能力与订阅层级会变化，组织应以当前管理控制台和官方说明核验 Kerberos、NTLM、SOCKS5 等能力，再下发锁定策略。
企业 TLS 中间人 CA 需要建立两层信任：Windows 把根证书导入受控的“受信任的根证书颁发机构”，macOS 把它导入 System Keychain 并明确设置信任，重启 Desktop 后再验证 docker pull；业务容器还要把 CA 安装进自己的系统或语言信任库，才能访问被拦截的 HTTPS。只在宿主机导入证书，不能自动保证每个镜像里的 Java、Node.js 或 Python 信任它。CA 更新要触发 Desktop 重启、镜像重建和握手回归。
context 是生产权限的最后一道误操作边界
Docker Desktop 启动时通常把客户端切到 desktop-linux。如果开发机还保存远端 context，一条普通的 docker rm 可能作用到远端 daemon。项目脚本应在写操作前断言 context：
expected=desktop-linux
actual="$(docker context show)"
if [ "$actual" != "$expected" ]; then
printf 'refuse: expected context %s, got %s\n' "$expected" "$actual" >&2
exit 23
fi还要检查 DOCKER_HOST、DOCKER_CONTEXT 和 TLS 环境变量，因为它们可能覆盖配置。远端生产 daemon 不应暴露未认证 TCP，开发机也不应长期保存高权限客户端证书。更稳妥的方式是让发布系统拥有受控凭证，开发机只保留本地 context。
Kubernetes 开关是一套额外控制面
Desktop 可以创建本地单节点或多节点 Kubernetes 环境，但打开开关会额外占用 CPU、内存、磁盘和网络，并改写或增加 kubeconfig context。它适合验证 manifest、控制器交互和本地集群 API，不会把 Desktop 变成生产集群，也不能证明云上存储、负载均衡、身份和多可用区行为。
启用前记录当前 context：
docker context show
kubectl config current-context 2>/dev/null || true
kubectl config get-contexts 2>/dev/null || true启用后先确认节点 Ready，再部署一个无状态探针。关闭或重置 Kubernetes 前导出需要保留的本地 manifest 和测试数据。Reset Kubernetes cluster 会删除 Kubernetes 资源；Clean / Purge data 与恢复出厂设置影响更大，不能把它们作为普通的“重启集群”。
诊断顺序要保留故障证据
CLI 报 daemon 不可达
依次执行：
docker context show
docker context inspect
docker version
docker info然后确认 Desktop 应用状态、虚拟化后端、WSL 或 Hyper-V 健康。Windows 再执行：
wsl.exe --status
wsl.exe -l -v
Get-Service com.docker.service -ErrorAction SilentlyContinue如果 context 指向错误端点，切回正确 context；如果 WSL 本身失败，修复 WSL 后端；如果 Desktop 卡在启动，先收集诊断包。重装是最后动作，因为重装可能改变数据位置和配置，却不一定修复被安全策略禁用的虚拟化。
Desktop 仍能响应 CLI 时可执行 docker desktop diagnose；完全无法启动时，在 Troubleshoot 中选择 Get support，或调用安装目录里的 com.docker.diagnose。诊断收集可能包含用户名、本机路径、代理和 registry 地址，先查看本地归档并按组织流程脱敏，再决定是否上传生成 Diagnostic ID；不要把诊断包直接附到公开 Issue。
镜像、容器或 volume 突然看不见
docker context ls
docker info --format '{{.Name}}|{{.DockerRootDir}}'
docker ps -a
docker volume ls先排除 context、后端、Windows/Linux container 模式和用户账户变化。数据“不可见”不等于已删除；切换后端或 context 会展示另一套对象。恢复前不要创建同名空 volume 覆盖判断现场。
磁盘持续增长
docker system df -v
docker buildx du
docker ps -a --size镜像层、容器可写层、volume、BuildKit cache 和 Desktop 虚拟磁盘是不同对象。先定位增长来源，再按项目标签、builder 或明确 volume 名清理。虚拟磁盘文件没有立刻缩小不代表清理无效，也不能直接删除磁盘文件。
重启、重置与卸载是四个不同风险等级
Restart Docker Desktop：重启应用与受管运行时，通常保留镜像、容器、volume 和设置。Reset Kubernetes cluster：删除本地 Kubernetes 工作负载与集群状态，Docker 对象不等于都会删除。Clean / Purge data：重置全部 Docker 数据并丢失现有设置，镜像、容器、volume 与缓存不能再假定可恢复。
Reset to factory defaults：把 Desktop 的全部选项恢复到初始状态；执行前同样按数据破坏操作准备恢复证据。
执行第三、第四级动作前，必须先记录 docker context ls、docker system df -v、关键 volume 清单和镜像来源；对需保留的数据，使用应用级导出或经过恢复演练的备份。docker commit 不是数据库备份，复制正在写入的虚拟磁盘也不是一致性备份。
卸载同样不等于自动安全删除所有数据与凭证。企业设备退役时要按目标平台核对虚拟磁盘、Docker 配置目录、凭证存储、企业 CA、远端 context 和诊断包；个人 token 应在服务端撤销，而不是只删本地文件。
从个人工具升级为团队基线
团队不应只发一个下载链接。可治理的 Desktop 基线包含设备支持矩阵、安装模式、后端、版本通道、资源档位、代理、证书、允许的 registry、升级节奏和数据重置流程。每次升级先在代表性 Windows/Intel Mac/Apple silicon 设备上跑四类回归：镜像拉取、源码 bind mount、端口转发、项目完整构建。
许可不是静态技术参数。Docker Desktop 的商业使用门槛、政府实体规则、功能套餐和价格可能变化，采购或平台 owner 应在部署和续期时重新核验官方条款、组织规模与用途，保存结论和审批；资产台账记录核验时间、适用组织和责任人，不能把某个日期的价格当成永久事实。
长期观测至少包括 Desktop 版本分布、启动失败率、冷构建时间、镜像拉取失败率、代理认证失败、虚拟磁盘增长、异常重置次数和许可证覆盖。诊断包可能包含本机路径、用户名、代理、registry 地址和日志，上传工单前先按安全流程审查，保留期限到期后删除。
当团队能回答下面的问题，Docker Desktop 才从个人软件变成了可靠开发底座：CLI 正在连接哪一个 daemon；项目数据在哪个虚拟磁盘和 volume；代理与 CA 分别作用于哪条流量；升级失败如何回到上一基线；重置前怎样证明数据可恢复；离职与设备退役时哪些凭证必须撤销。