核心是区分单机环境（用顶级字段如mem_limit、cpus）和swarm集群环境（必须用deploy.resources），混用会导致限制不生效；还需补充memory_swap、blkio_weight等防溢出与io打满，并用docker stats和docker inspect验证实际配置。
在 docker-compose.yml 中配置资源限制，核心是区分两种使用场景：单机开发/测试环境（用顶级字段）和生产集群环境（用 deploy.resources）。不加区分地混用会导致限制不生效——这是最常被忽略的问题。
单机环境用顶级字段（docker-compose up 直接生效）
适用于本地调试、CI/CD 构建节点或非 Swarm 的生产单机部署。Docker Compose 会直接将这些参数透传给容器运行时：
-
mem_limit：硬性内存上限，超限后容器会被 OOM killer 终止（如
512m、2g） - mem_reservation：软性预留值，告诉内核“这个容器至少需要这么多内存”，用于 cgroups 内存回收触发时机
-
cpus：限制可使用的 CPU 时间比例（如
0.75表示最多占用 0.75 个逻辑核心） -
cpu_shares：相对权重，默认 1024；当多个容器竞争 CPU 时，按比例分配时间片（如设为
512表示只有默认值一半的优先级）
示例：
version: '3.8'
services:
api:
image: my-api:latest
mem_limit: 1g
mem_reservation: 512m
cpus: 1.2
cpu_shares: 800
Swarm 集群环境必须用 deploy.resources
如果你通过 docker stack deploy 运行，或者启用了 Swarm 模式，mem_limit 和 cpus 等顶级字段会被忽略。必须使用 deploy.resources 结构：
-
limits.memory：等同于
mem_limit，超限即 kill -
reservations.memory：等同于
mem_reservation，影响调度器是否把该服务调度到内存紧张的节点 -
limits.cpus：硬性 CPU 配额（字符串格式，如
'1.5'） - reservations.cpus：最小保障 CPU，用于服务启动前的资源预留判断
示例：
version: '3.8'
services:
worker:
image: my-worker:latest
deploy:
resources:
limits:
cpus: '2.0'
memory: 2g
reservations:
cpus: '0.5'
memory: 512m
别漏掉 swap 和 IO 控制（防内存溢出与磁盘打满）
仅限内存和 CPU 不够全面。真实生产中还需补充：
-
memory_swap：配合
mem_limit使用，控制总内存（RAM + swap），避免 swap 耗尽拖垮整机（如mem_limit: 512m+mem_swap: 1g） - blkio_weight：设置块设备 I/O 权重（10–1000），防止某个服务疯狂读写磁盘影响其他容器（需宿主机支持 blkio cgroup v1）
-
oom_kill_disable：慎用！设为
true可禁用 OOM killer，但可能导致系统卡死，仅用于特殊调试
验证是否生效的三个关键命令
配完不能只信 YAML，要动手确认：
-
docker-compose ps：查看服务状态，确认没因资源不足反复重启 -
docker stats <container_name></container_name>：实时看内存/CPU 实际使用率是否卡在限制线内 -
docker inspect <container_id> | grep -A 10 -B 5 memory\|cpu</container_id>：查底层 cgroup 配置是否已写入，比如"Memory": 536870912对应 512MB
