单机也要设资源上限
在服务的 deploy.resources.limits 下声明 CPU 与内存上限，Compose V2 在单机运行时同样生效，用来防止单个服务吃光宿主的 CPU 或内存。老版本的 mem_limit 与 cpus 属于 V1 风格写法，与 deploy.resources 混用会让人搞不清哪一套在生效，建议统一到 deploy.resources 一种写法。
基本信息
| 限制 | deploy.resources.limits，CPU 用 cpus 字符串，内存用带单位的值 |
|---|---|
| 预留 | deploy.resources.reservations，单机 Compose 语义有限，主要用于表达意图与编排兼容 |
| 旧写法 | mem_limit 与 cpus，属于 V1 时代风格 |
| 验证方式 | docker stats 看实时用量，docker inspect 的 HostConfig 看实际生效值 |
| 单位要求 | 内存必须带单位，M 与 G 的数量级差异很大 |
| 与 swap 的关系 | 内存上限与 swap 上限需要一并考虑，否则压力会被 swap 掩盖 |
典型使用场景
- 单机多服务共存，避免某个服务吃光 CPU 或内存影响其他服务
- 给批处理与定时任务设上限，防止与在线服务抢占资源
- 开发机上限制资源占用，避免整机卡顿影响其他工作
- 压测前给被测服务设上限，模拟生产的资源约束条件
- 应急时先用 docker update 临时收紧，再回到 compose 里固化配置
示例
示例
services:
web:
image: myapp:1.2.3
deploy:
resources:
limits:
cpus: "1.5" # CPU 上限，写成字符串
memory: 512M # 内存上限，必须带单位
reservations:
cpus: "0.5" # 预留，单机模式下语义有限
memory: 256M
# 验证
docker stats --no-stream # 看实际用量与上限对比字段与常见错误
| 字段 | 含义 | 常见错误 |
|---|---|---|
| limits.cpus | CPU 上限，可取小数 | 写成数字类型，部分版本解析与预期不同 |
| limits.memory | 内存上限 | 忘记单位被当作字节，容器启动即失败 |
| reservations | 资源预留 | 误以为单机模式会独占资源，实际主要是表达意图 |
| mem_limit 与 cpus | 旧写法 | 与 deploy 同时写，两套值纠缠难以判断生效项 |
| 单位后缀 | M 与 G 等 | 混淆 M 与 Mi，容量与预期不一致 |
容器内存超限表现为 OOMKilled（退出码 137）：调小限制之前先看应用的实际峰值，用 docker stats 或监控数据确认数值，而不是先猜一个再试。
只设上限不设预留也不做容量规划，多个服务在高峰期仍会相互挤占：单机场景下资源是共享的，上限只能防止单个服务失控，不能保证关键服务一定拿到资源。