必须显式设置内存和CPU限制，否则容器可能耗尽宿主机资源导致卡死或内核panic；内存需用-m与--memory-swap同步设定（如-m 512m --memory-swap=512m），CPU须用--cpus硬限制（如--cpus 1.25），docker-compose中对应cpus: '1.0'和memswap_limit: 512M。
在 Mac 上用 Docker Desktop 运行容器时，必须显式设置内存和 CPU 限制，否则容器可能吃光宿主机资源导致系统卡死、Docker Desktop 自动重启甚至 macOS 内核 panic；默认不限制，不是“够用就好”。
限制容器最大内存使用量
直接用 -m 或 --memory 参数指定物理内存上限，但【必须同步设置 --memory-swap】，否则 Docker 会默认启用等量 swap，实际可用内存翻倍，OOM 行为完全失控。
方法一：禁用 swap，严格按物理内存限制执行docker run -m 512m --memory-swap=512m nginx
这表示容器最多用 512MB 物理内存，且禁止使用任何 swap 空间。Mac 上 swap 文件由系统管理，Docker 不应绕过它。
方法二：允许有限 swap（仅调试用）docker run -m 512m --memory-swap=768m nginx
此时内存 + swap 总和不能超过 768MB，其中最多 512MB 是物理内存，剩余 256MB 可来自 swap。生产环境不建议——Mac 的压缩内存机制（Compressed Memory）与 Docker swap 交互不可预测，容易触发内核 memory pressure 告警。
注意：--memory-reservation 是软限制，在 Docker Desktop for Mac 上效果极弱，因为 macOS 内核不支持 cgroup v1 的 memory.soft_limit_in_bytes，该参数基本被忽略。
限制容器最多使用的 CPU 核心数
Docker Desktop for Mac 底层通过轻量级虚拟机（HyperKit）运行 LinuxKit，CPU 调度最终落在 macOS 的 Hypervisor 框架上，因此【--cpus 是唯一推荐的硬限制方式】，它能精确映射到虚拟 CPU 配额，其他参数如 --cpu-shares 在 macOS 上响应迟钝且不可靠。
第一步：启动容器时直接指定核心数上限docker run --cpus 1.25 nginx
表示该容器最多占用 1.25 个逻辑 CPU 核心的计算时间，即使宿主机有 10 核，它也绝不会突破此配额。小数合法，Docker 会自动换算为 cpu-quota/cpu-period 值写入 cgroup。
第二步：验证是否生效docker stats 容器名
观察 CPU % 列——若长期稳定在 125%（对应 1.25 核），说明限制已起效；若冲到 300%+，说明参数未正确传入或容器启动失败后被自动重启覆盖了配置。
第三步：检查底层配置是否写入docker inspect 容器名 | grep -A 3 NanoCpus
输出类似 "NanoCpus": 1250000000 即正确（1.25 × 10⁹ nanocores）。这个值是 Docker Desktop 实际提交给虚拟机的硬配额，不可绕过。
用 docker-compose 统一配置多容器资源限制
适合本地开发环境批量管控，避免每次 run 都手敲参数。Docker Desktop for Mac 完全支持 Compose v3+ 的资源语法，但注意字段格式必须严格匹配：
在 docker-compose.yml 中写：
```yaml
version: '3.8'
services:
web:
image: nginx
deploy:
resources:
limits:
cpus: '1.0'
memory: 512M
memswap_limit: 512M
```
cpus 必须是字符串（带引号），否则 Compose 解析失败；memswap_limit 是 --memory-swap 的 YAML 等价写法，Mac 上必须与 memory 值一致。
启动命令：docker-compose up -d。此时所有服务实例都会继承该限制，无需额外干预。
