Docker Desktop 怎样给容器设置资源上限

Docker Desktop 中有两层资源限制：Settings 的资源页面控制 Linux 虚拟机的总额度；单个容器的 CPU、内存和交换使用规则应通过容器运行参数设置。只把 Desktop 内存滑块调到 4GB，并不等于每个容器各有 4GB 上限。

官方地址：https://docs.docker.com/desktop/。本篇面向 Docker Desktop 中的 Linux 容器，用独立演示容器说明参数，不覆盖 Windows 容器、集群调度或生产容量规划。所有界面配图是 ImageGen 原创说明图，命令没有在本文制作过程中执行。

1. 在Resources中确认总额度与后端

打开 Docker Desktop Dashboard，点击 Settings 齿轮 → Resources → Advanced。在 macOS、Linux Desktop 或 Windows Hyper-V 后端，可在这里查看 CPU limit、Memory limit 和 Swap。先记录原值；只有共享预算确实不足且宿主机留有余量时才调整。

这些设置面向整个 Docker Linux 虚拟机。若需要改动，保存工作，并按当前版本出现的 Apply 或重启提示应用设置，预留现有容器可能中断的时间。这里不要求为了示例修改全局额度，已有额度足够即可。

完成状态：能辨认三项全局资源字段及其当前值，知道它们不是某一个容器的配置。若页面因后端不同而没有这些滑块，不要在其他页面寻找同名“容器配额”代替。

Windows 使用 WSL 2 后端时，CPU、内存和 swap 应在 WSL 2 utility VM 的设置层管理，不照搬 Hyper-V 的 Advanced 滑块路径。先确认后端，再按对应官方文档配置；本文后面的容器参数同样以 Linux 容器和内核支持为前提。

2. 给独立演示容器传入资源参数

在宿主机可访问 Docker Desktop CLI 的终端中执行下面的演示命令；不要进入某个业务容器的 Exec 页面运行它。这里用 CLI 创建容器，是为了把三个限制明确写在同一处，不虚构 Dashboard 存在通用的逐容器资源编辑开关。

# 只创建独立演示容器；同名容器存在时先换一个演示名称
# 不挂载业务目录、不发布端口；镜像缺失时可能联网拉取
docker run -d --name resource-cap-demo --cpus=1 --memory=256m --memory-swap=384m alpine:3.22 sleep 1800

此例让容器运行一个低负载等待进程，便于查看配置，不制造耗尽资源的压力。CPU 额度不是独占核心或性能保证；256m 是容器内存额度，384m 是内存加交换的总额度，差额 128m 才是可允许的交换部分，且还受虚拟机实际可用 swap 与内核能力约束。

不要把 --memory-swap=0 理解成禁止交换；这个值按未设置处理。若出现内核不支持 swap 限制的警告，就不能声称该部分限制已经生效。也不要以关闭 OOM 处理的方式掩盖内存不足，额度太小需要重新评估应用需求。

然后返回 Desktop 的 Containers，在搜索框输入 resource-cap-demo。完成状态：列表出现这个名称，状态为 Running；若镜像拉取或启动失败，先处理具体错误，不把“命令输入过”当作创建成功。

3. 在容器详情中查看限制而非仅看使用量

在 Containers → resource-cap-demo → Inspect 打开容器配置详情，查看 HostConfig 中的 Memory、MemorySwap 与 NanoCpus。如果界面显示不便于查找，可在宿主机使用下面的只读命令提取同一容器的对应字段。

# 只读查看演示容器的配置，不调整现有容器
docker inspect resource-cap-demo --format 'CPU额度={{.HostConfig.NanoCpus}} 内存={{.HostConfig.Memory}} 内存加交换={{.HostConfig.MemorySwap}}'

按照前面的参数，预期 NanoCpus 为 1000000000，Memory 为 268435456 字节，MemorySwap 为 402653184 字节。这些是配置换算的预期值，不是实测日志。Inspect 反映配置，仍需结合前述内核支持情况解释，不能单凭配置字段证明所有环境都实际执行了限制。

再点击 Stats 查看即时用量。一个只执行 sleep 的容器可能一直用量很低，这不说明配额失效，也不证明应用在高负载下足够稳定。不要为了让曲线“顶满”而随意给本机或业务容器施加负载。

完成状态：已定位正确的容器，配置值与预期一致，并能区分 Inspect 中的限制与 Stats 中的使用情况。此时才算完成本例设置与查看流程。

演示结束后，可在 Containers 中只对 resource-cap-demo 执行 Stop，再确认目标名称后删除这个演示容器。不要执行全局清理，也不要连带删除业务容器或卷。若之前改过全局设置，按记录恢复原值并安排必要的重启。

调小Desktop内存会自动给每个容器均分吗？

不会。共享预算与单容器限制是不同层次，也不能把所有容器上限简单相加后认为资源已经被预留。多个容器同时活跃时仍可能互相竞争。

已有Compose服务应该怎样处理？

在服务的声明式配置中维护限制，再按项目流程重新创建并检查对应容器。不要把一次性演示命令当成已修改 Compose 文件；本篇不展开 Compose 的资源字段。

为什么容器内free显示的swap和设置不同？

容器内通用内存工具可能显示宿主层的可用交换信息，不宜用它单独判断容器交换额度。应结合运行参数、配置字段和后端支持情况。

官方设置入口说明：https://docs.docker.com/desktop/settings-and-maintenance/settings/；容器参数含义：https://docs.docker.com/engine/containers/resource_constraints/；Dashboard 容器详情：https://docs.docker.com/desktop/use-desktop/container/。