docker info显示的是Docker Desktop引擎的静态配置上限（如Total Memory、NCPU），而非宿主机实时资源使用量；真实占用需用docker system df查磁盘、docker stats看运行中容器的CPU和内存流。
直接看 docker info 就能拿到 Docker Desktop 引擎当前的资源视图，但要注意它只反映容器运行时的配置上限，不等于宿主机真实剩余资源。
docker info 显示的是引擎配额，不是实时使用量
docker info 输出里最关键的几行是：
-
OSType和Architecture：确认底层虚拟化后端（WSL2 / Hyper-V / Apple Virtualization） -
Total Memory和NCPU：这是 Docker Desktop 在设置里手动分配给引擎的上限值，比如你设了 4GB 内存，这里就写Total Memory: 4.00GiB，哪怕宿主机只剩 500MB，它也照写不误 -
Driver和Root Dir：指向/var/lib/docker所在位置，决定 volume 和镜像实际落盘路径
这个命令不刷新、不采样，纯静态配置快照。想看“此刻用了多少”，得换别的命令。
docker system df 查看磁盘空间实际占用
磁盘是 Docker Desktop 最容易卡死的瓶颈，docker system df 是唯一能直接告诉你“哪块占得多、哪块能删”的命令：
- 输出四类资源：
Images、Containers、Local Volumes、Build Cache，每行带RECLAIMABLE值——这个数字才是你能立刻动手腾的空间 - 加
-v参数后，Images段会列出每个镜像 ID 和仓库名，注意: Build Cache段里如果显示几百 MB 可回收，大概率是多阶段构建残留 - 别信
SIZE列总和，du -sh /var/lib/docker才是真实体积，两者差得远很正常，因为 overlay2 层共享、硬链接、ext4.vhdx 文件系统压缩都会干扰统计
docker stats 看 CPU 和内存实时流
docker stats 是唯一能盯住“正在跑的容器”资源水位的命令：
- 默认只显示运行中容器，加
--all也没用，已停止的容器不推数据 - 内存列显示的是 cgroup 总用量减去 page cache 后的值（Linux 上），所以比
top里看到的 RSS 小；macOS 上数值更接近真实压力 - 如果某容器
MEM USAGE / LIMIT长期贴着上限，但docker info里Total Memory还很宽裕，说明问题不在引擎配额，而在容器自身没设--memory限制，或者应用有内存泄漏 - 想导出快照而非持续流，加
--no-stream，适合写进监控脚本
Windows 上 vmmemWSL 进程吃光内存怎么办
这是 WSL2 后端特有的“黑盒”现象：任务管理器里 vmmemWSL 占满 8GB，但 docker stats 加起来才 1GB —— 因为 WSL2 的内存是动态伸缩的，不主动释放，只在宿主机压力大时才交还。
- 临时缓解：在 PowerShell 里运行
wsl --shutdown，强制重启 WSL2 实例，内存立刻清零 - 长期控制：进 Docker Desktop 设置 → Resources → WSL Integration，关掉不用的发行版；再进 Advanced，把 Memory 调低（比如从默认 4GB 改成 2.5GB），它会写入
%USERPROFILE%\AppData\Local\Packages\...\wsl.conf - 别碰
swap和localhostForwarding，这两个开关一开反而更容易锁死内存
真正难搞的从来不是“怎么查”，而是查完发现 docker system df 说能删 2GB，docker system prune -a 却只腾出 200MB——那多半是 /var/lib/docker/volumes 下某个 volume 里塞了日志文件或数据库文件，得手动进对应路径用 du -sh 挖。
