docker stats 显示空闲但 CPU 持续偏高，问题不在容器而在 Docker Desktop 自身管理进程或 WSL2 底层：com.docker.backend 执行后台任务（如镜像同步、更新检查），vmmemWSL 作为 WSL2 虚拟机持续调度与维护，即使无容器运行；需通过 Get-Process 查看其 CPU 占用、检查 backend.log 错误日志，并配置 %USERPROFILE%.wslconfig 限制内存与 CPU 才能根治。
docker stats 显示空闲但 CPU 持续偏高
这不是容器的问题，而是 Docker Desktop 自身管理进程或 WSL2 底层在“偷偷干活”。docker stats 只显示容器级资源，它完全不反映 com.docker.backend、Docker Desktop.exe 或 vmmemWSL 这些宿主进程的 CPU 消耗。你看到的高 CPU，大概率来自：
-
com.docker.backend：负责镜像拉取、构建缓存清理、Docker Hub 同步、自动更新检查等后台任务，即使没跑容器也会周期性唤醒 -
vmmemWSL：WSL2 虚拟机内核本身在做内存压缩、页回收、网络栈维护，尤其当 WSL2 内存配额宽松时，这些动作更频繁 - Windows Defender 实时扫描：Docker Desktop 的
\wsl$共享路径、镜像层文件（C:UsersXXXAppDataLocalDockerwsldata）可能被反复扫描
检查 com.docker.backend 是否在轮询或卡死
这个进程是 Docker Desktop 的“大脑”，但它没有公开健康状态接口。最直接的验证方式是观察其行为模式：
- 打开 PowerShell，运行：
Get-Process -Name "com.docker.backend" | Select-Object CPU, StartTime, Id—— 如果CPU值长期 >10% 且StartTime是几分钟前（说明刚重启过），大概率是它在重试失败任务 - 查看日志：
cd "$env:LOCALAPPDATADockerlogackend"，打开最新backend.log，搜error或retry，常见于镜像仓库认证失败、代理配置错误、或~/.docker/config.json里有残留的无效 registry 登录项 - 临时停用它：
Stop-Process -Name "com.docker.backend" -Force，再等 10 秒看 CPU 是否回落。如果回落明显，问题就锁定了
WSL2 空闲时 vmmemWSL 仍吃 CPU 的真实原因
WSL2 不是“暂停”状态，它是持续运行的轻量虚拟机，哪怕所有容器都 docker stop 了，它的内核仍在调度、处理中断、维护 cgroups。以下情况会让它更“活跃”：
- WSL2 默认未启用
systemd，但 Docker Desktop 启动时会绕过 systemd 直接拉起一堆服务（如dockerd、containerd、dbus），这些服务即使空闲也会保活心跳 -
/etc/wsl.conf中未设置automount = false或networking = false，导致 WSL2 持续监听 Windows 主机网络变化、挂载盘符变更事件 - WSL2 分发版内核版本太老（比如 Ubuntu 20.04 自带的 5.4.x），对空闲态功耗优化差；建议升级到 22.04+ 并手动更新内核：
wsl --update --web-download
快速止血：关掉非必要后台行为
不用卸载重装，几条命令就能压住空转 CPU：
- 禁用自动更新检查：
Settings → General → Automatically check for updates关掉（图形界面最稳） - 清空无效 registry 登录：
docker logout所有非当前使用的 registry，再删掉~/.docker/config.json里对应auths字段 - 限制 WSL2 资源上限（关键）：在
%USERPROFILE%wsl.conf里加：
#[wsl2] memory=2GB processors=2 swap=0
然后执行：wsl --shutdown，再重启 Docker Desktop。这个配置能强制 WSL2 内核在空闲时更快进入低功耗状态，而不是无限制地“呼吸”。
真正难搞的不是 CPU 占用数字本身，而是它背后混合了 Windows 进程模型、WSL2 虚拟化层、Docker 后台服务三套调度逻辑——任何一层的 idle 策略没对齐，就会互相唤醒，形成“空转震荡”。所以别只盯着 docker stats，得从 vmmemWSL 和 com.docker.backend 这两个真实消耗者入手。
