--cpu-shares仅在CPU资源争用时按权重比例分配时间片，非硬限制；默认值1024，值越大竞争中获得CPU时间越多，空闲时容器可使用全部可用CPU。
--cpu-shares 参数在 Docker Desktop 中完全可用，但它的效果容易被误判——它只在 CPU 资源争用时起作用，且仅对同主机上共存的容器生效。Docker Desktop 底层仍是 Linux 容器（通过 WSL2 或 Hyper-V），所以 --cpu-shares 的行为和原生 Linux Docker 一致，不是“桌面版特有功能”。
--cpu-shares 在 Docker Desktop 中为什么看起来没效果？
Docker Desktop 默认启动的容器往往独占宿主机资源（尤其开发场景下只有 1–2 个容器），CPU 不争用 →
--cpu-shares不触发调度权重计算Windows 主机本身不直接运行容器，实际调度发生在 WSL2 的 Linux 内核中；若 WSL2 分配的 CPU 核心数过少（如默认 2 核），容器间竞争不明显
docker stats显示的是绝对使用率（如 150%），无法直接反映份额比例分配结果确保至少两个容器同时运行 CPU 密集型任务（比如
stress-ng --cpu 2）检查 WSL2 分配的 CPU 数量：在
%USERPROFILE%\AppData\Local\Packages...\wsl.conf中确认是否设置了processors=4不要依赖单个容器的
docker stats数值判断份额是否生效；要用top -H进入容器内部，或对比两个容器在满负载下的实际 CPU 时间占比
如何在 Docker Desktop 中正确设置并验证 --cpu-shares
启动两个不同权重的容器，并强制制造 CPU 竞争：
# 启动高权重容器（2048） docker run -d --name cpu-high --cpu-shares 2048 ubuntu:22.04 tail -f /dev/null # 启动低权重容器（512） docker run -d --name cpu-low --cpu-shares 512 ubuntu:22.04 tail -f /dev/null # 进入各自容器，同时执行 CPU 压测（需提前安装 stress-ng） docker exec -d cpu-high sh -c "apt update && apt install -y stress-ng && stress-ng --cpu 2" docker exec -d cpu-low sh -c "apt update && apt install -y stress-ng && stress-ng --cpu 2"
验证方式：
-
查看实际 cgroup 权重：
docker inspect cpu-high | grep CpuShares→ 应返回"CpuShares": 2048docker inspect cpu-low | grep CpuShares→ 应返回"CpuShares": 512 登录 WSL2（
wsl -d docker-desktop），查看对应 cgroup：cat /sys/fs/cgroup/cpu/docker/*/cpu.shares观察
docker stats输出中两容器的 CPU % 是否稳定呈现约 4:1 的比例（2048:512 = 4:1）
Docker Desktop 下 --cpu-shares 的常见陷阱
--cpu-shares不能和--cpus混用做“双重保障”：后者是硬限制（如--cpus=0.5），前者在资源不争用时完全不干预；两者逻辑层级不同，冲突时以--cpus为准Docker Desktop for Mac 使用虚拟化层（HyperKit），
--cpu-shares仍有效，但 macOS 内核不参与调度，最终由 Linux VM 内的 CFS 执行，延迟略高-
如果你在 Docker Compose 中使用，必须写在服务顶层（非
deploy.resources）：services: app: image: nginx cpus: 1.0 mem_limit: 512m
deploy.resources在 Docker Desktop 单机模式下被忽略 --cpu-shares最小值是 2，不是 0 或 1；设为 2 和 4 时，比例仍是 1:2，但内核可能因精度舍入导致微小偏差容器重启后配置丢失：Docker Desktop 不保存运行时参数，每次
docker run都需显式指定，或改用docker-compose.yml固化
Docker Desktop 的 --cpu-shares 机制本身没问题，问题常出在验证方法不对、竞争条件未构造、或误以为它能限制单容器上限。真正需要硬限流时，优先用 --cpus；要协调多个容器间的相对公平性，才轮到 --cpu-shares ——而这个“公平”，只在它们真正在抢 CPU 的那一刻才看得见。
