daemon.json 不能设置容器默认内存或 cpu 配额，仅支持守护进程级资源预留（如 memory-reservation、cpu-reservation）和全局行为控制；容器级硬限制必须通过 docker run 参数、docker-compose.yml 或编排工具显式指定。
daemon.json 不能直接设置容器的默认内存或 cpu 配额，它只支持全局性、守护进程级的资源预留（如 memory-reservation）和默认运行时行为控制，但不提供 --memory 或 --cpus 这类容器级硬限制的默认值。真正能“默认生效”的资源约束，必须靠运行时参数或编排工具实现。
真正有效的默认内存限制方式
daemon.json 中没有 "default-memory": "512m" 这样的字段。要让所有容器默认受限，需结合以下两种方式：
-
强制使用 runtime 约束 + 容器启动规范：在 daemon.json 中启用实验特性并配置基础策略，但实际限制仍需在
docker run或docker-compose.yml中显式写入--memory和--memory-swap；否则容器仍可无限制使用内存 -
务必配对设置 --memory 和 --memory-swap：只设
-m 512m会导致 swap 自动开到 1G（即总上限 1G），正确禁用 swap 应写为-m 512m --memory-swap=512m；否则 OOM 行为不可控，top 看到的使用量会远超预期 -
推荐配合 cgroup v2 和 systemd 级防护：确认宿主机已启用 cgroup v2（
mount | grep cgroup2），并在/etc/systemd/system/docker.service.d/override.conf中为 dockerd 进程自身加MemoryLimit=2G，防止构建镜像等操作吃光整机内存
CPU 默认配额的可行路径
daemon.json 同样没有 "default-cpus" 字段。所谓“默认”，只能通过间接手段落地：
-
用 default-ulimits 控制 CPU 相关资源：例如设置
"nofile"或"nproc"上限，虽不等于 CPU 核心数限制，但可防 fork 爆炸类失控 -
通过 --cpu-quota / --cpu-period 实现时间片级默认控制：虽然不能写进 daemon.json，但可在 CI/CD 模板或容器启动脚本中统一注入，比如固定使用
--cpu-quota=50000 --cpu-period=100000（即 50% CPU 时间） -
借助 docker-compose 的 deploy.resources.limits：在编排文件中定义服务级默认值，比单个 run 命令更易统一管理，例如：
limits: { cpus: '1.0', memory: '512M' }
daemon.json 中唯一相关的“预留”参数
它不设容器配额，但能为系统留出安全余量，避免被容器挤占关键资源：
-
"memory-reservation": "1g"：告诉 dockerd 启动时向内核预申请 1GB 内存，这部分不会被调度给容器——但不是容器内存上限，只是守护进程启动阶段的软预留 -
"cpu-reservation": "0.5"：同理，表示为系统保留半颗 CPU 的调度能力，同样不约束单个容器 - 这两个参数需开启
"experimental": true（Docker CE 20.10+ 默认开启），且必须配合 systemd 的MemoryLimit和CPUQuota才构成完整防护
为什么不能依赖 daemon.json 做默认配额
这是设计使然：Docker 将资源限制视为容器生命周期的一部分，由用户在启动时明确声明，而非由守护进程隐式赋予。这种设计保障了可预测性与透明性——没写的限制，就是没限制。强行在 daemon.json 中幻想“全局默认内存”，反而会掩盖真实风险，导致误判容量规划。
