在 Docker Desktop 设置中调低 CPU 核心数可直接限制其底层虚拟机（WSL2 或 HyperKit）的总资源占用，是缓解宿主机卡顿最有效手段；macOS 通过 Settings → Resources → Advanced 设置 cpus（建议物理核数的 50%~75%），Windows 则需配合修改 .wslconfig 文件并执行 wsl --shutdown 才真正生效。
怎么在 Docker Desktop 设置里调低 CPU 核心数
直接改 Docker Desktop 自身能用的 CPU 上限，是解决 Mac/Windows 本地卡顿最立竿见影的办法。它不作用于单个容器，而是限制背后那个 Linux 虚拟机（WSL2 或 HyperKit）最多能抢走多少宿主机资源。
操作路径很明确：点击右上角 Docker 图标 → Settings → Resources → Advanced（macOS）或 Settings → Resources → WSL Integration（Windows）。关键不是“开不开”，而是填对数值：
-
cpus：建议设为物理核心数的 50%~75%。比如你笔记本是 16 核（8P+8E），别填 16，填6或8更稳；填0无效，填use all CPUs是默认但危险选项 - Windows 用户必须额外配
.wslconfig文件才真正生效。只在 Docker Desktop UI 里调cpus值，对 WSL2 底层没约束力 - 改完一定要点 Apply & Restart，否则只是纸上谈兵
运行容器时用 --cpus 限制单个服务的 CPU 占用
全局调低只是保底，真正要防某个容器（比如一个没加限流的 Python Web 服务）把 CPU 打满，得在启动时加 --cpus。这是目前最推荐、最直观的硬限制方式。
它背后自动转成 cgroup 的 --cpu-quota/--cpu-period，你不用碰底层参数：
-
--cpus=1.5表示该容器最多占用 1.5 个逻辑核的算力，系统空闲时可以跑满，争抢时会被掐断 -
--cpus=0.3适合后台任务（如日志轮转、定时同步），避免它偷偷吃掉 30% 的单核时间 - 注意：这个限制在 Docker Desktop 的 Windows/macOS 上是软性的，实际效果依赖 WSL2 或 HyperKit 的调度实现，Linux 主机上才是真硬限
- 别和
--cpu-shares混用。--cpu-shares是权重，只在多个容器争资源时起作用，单独一个容器填512或2048都没区别
为什么 --cpuset-cpus 和 --cpu-quota 很少需要手动配
除非你在做性能压测、混部高 SLA 服务，或者排查特定 NUMA 绑核问题，否则没必要碰这两个参数。
--cpuset-cpus 是绑核，比如 --cpuset-cpus="0-1" 强制容器只跑在 CPU 0 和 1 上。但它不控制用量，绑了两核照样能把这两核打满；--cpu-quota 必须配合 --cpu-period 才生效，单独设 --cpu-quota=50000 完全无效，因为默认 --cpu-period=100000，你要自己算清楚比例才能等效于 --cpus。
使用 ImageMagick 的 convert 和 mogrify 命令进行批量图像处理，支持调整大小、裁剪、水印和格式转换。与 libvips 集成以实现高性能缩略图生成。
真实场景中容易踩的坑：
- 在 docker-compose.yml 里写
cpus: 1.5，必须放在deploy.resources.limits下，且值是字符串类型：cpus: "1.5"，写成数字会报错 - 用
docker update动态改正在运行容器的--cpus，仅 Linux 有效，Docker Desktop 不支持热更新 -
--cpus对 Windows/macOS 上的桌面应用（如 VS Code 连容器调试）影响不大，但对 CPU 密集型构建（如npm run build）延迟敏感，建议实测
Docker Desktop 的 CPU 限制本质是虚拟机级隔离
很多人以为调了 --cpus 就万事大吉，其实 Docker Desktop 的特殊性在于：所有容器都跑在一个共享的 Linux VM 里。这个 VM 本身没被限，那它就能把宿主机 CPU 吃干抹净——哪怕你每个容器都设了 --cpus=0.1，加起来还是可能超。
所以真正的防线有两层：
- 第一层：通过
.wslconfig（Win）或 Docker Desktop UI 的cpus（Mac）锁死 VM 总量 - 第二层：用
--cpus在容器启动时做二次分流，防止某一个服务失控 - 中间没有第三层。别指望
--cpu-shares能当安全阀，它在单容器场景下完全不生效
复杂点在于，WSL2 的内存/CPU 限制不是实时生效的，wsl --shutdown 后再启 Docker Desktop 才算重置。这点常被忽略，导致调了配置却感觉“没用”。
