docker stats 是最轻量、最准的容器CPU监控起点，默认持续刷新，加 --no-stream 可输出单次快照；重点关注 CPU % 列，超100%表示使用多核，长期超80%需警惕异常。
docker stats 能直接看出哪个容器 CPU 最高
不用进 GUI 界面翻来翻去，docker stats 是最轻量、最准的起点。它默认持续刷新，按 Ctrl+C 可停；加 --no-stream 就只输出一次快照，适合脚本或快速扫一眼。
重点关注 CPU % 列：数值超过 100% 表示用了多核（比如 250% ≈ 2.5 核），长期稳定在 80% 以上就要怀疑是否异常。注意别被宿主机 top 里的 vmmemWSL（Windows）或 com.docker.deskto（macOS）进程带偏——那只是 Docker Desktop 自身虚拟化层的开销，和容器无关。
-
docker stats --no-stream：一次性列出所有运行中容器的实时占用 -
docker stats --no-stream --format "{{.Name}}\t{{.CPUPerc}}\t{{.MemPerc}}" | sort -k2 -nr：按 CPU 降序排列，一眼锁定大户 - 如果某容器
CPU %显示0.00%但实际业务卡顿，可能是它被--cpus=0.1这类极低配额限制死，不是不忙，是根本轮不到时间片
docker top 定位容器内具体吃 CPU 的进程
光知道哪个容器高 CPU 不够，得进到里面看是哪个线程或进程在狂转。用 docker top 比 docker exec -it xxx top 更干净——它不依赖容器里有没有 top 命令，也不用挂载 shell，直接读 cgroups 数据。
关键参数是 -o 和 --sort：
-
docker top nginx-container -o pid,%cpu,comm --sort=%cpu：只显示 PID、CPU 占比、命令名，并按 CPU 从高到低排 -
%cpu是该进程占「整个容器」CPU 时间的比例，不是宿主机全局比例。比如容器被限 1 核，某进程占了其中 95%，docker stats显示容器 CPU 是 95%，docker top就会标它 95% - 如果看到大量
sh、bash或python进程 CPU 很高，大概率是脚本里写了死循环、高频轮询或没设超时的阻塞调用
Windows 上 vmmemWSL 高 CPU 不等于容器问题
Docker Desktop for Windows 默认走 WSL2 后端，vmmemWSL 进程 CPU 飙高时，第一反应不该是查容器，而是先看 WSL2 本身有没有卡住。
- 运行
wsl -l -v确认当前发行版状态，再执行wsl -t Ubuntu（替换成你的发行版名）重启 WSL 实例，观察vmmemWSL是否回落 - 检查
%LOCALAPPDATA%\Packages\CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc\LocalState\ext4.vhdx文件大小——如果接近磁盘上限，WSL2 会频繁触发垃圾回收，拖慢整个虚拟机 - 只有确认
vmmemWSL降下来后，docker stats里容器 CPU 还高，才说明真问题是容器内部逻辑，不是虚拟化层抖动
Mac 上 com.docker.desktop CPU 高要先排除镜像构建
macOS 版 Docker Desktop 的 com.docker.desktop 进程 CPU 高，常见于后台正在做 docker build 或多阶段构建。它不像 Linux 那样把构建负载均摊给子进程，而是集中在主进程里调度。
- 运行
docker build --progress=plain .替代默认的 auto 模式，能看清当前卡在哪一层（比如 RUN pip install 卡住） - 检查
~/.docker/buildx/instances下是否有残留 builder 实例，用docker buildx rm清掉再试 - 如果刚 pull 过大镜像（如
tensorflow:latest），Docker Desktop 会在后台解压并转换 OCI 层，这个过程 CPU 占用高且不可跳过——等几分钟再看docker stats
真正容易被忽略的是：CPU 高不一定代表程序写得差，也可能是资源限制太紧导致调度器疯狂重试。比如一个本该用 1.5 核的应用，被 --cpus=0.5 死死卡住，docker stats 显示它 CPU 100%，其实是“饿”出来的假高压。
