deploy.resources 是最可靠、可移植且符合规范的资源限制方式，自 docker compose v2.15+ 起在 docker compose up（非 swarm）中也原生支持；其中 limits 设定硬性上限（如 cpus: "0.75"、memory: "1g"），超限触发 cgroup 限制或 oom 终止，reservations 提供软性预留（如 memory: "512m"），影响 memory.low 以提升调度保障。
直接在 docker-compose.yml 中通过 deploy.resources 设置 limits 和 reservations，是最可靠、可移植、符合 Compose 规范的方式。它不依赖 Swarm 模式——从 Docker Compose v2.15+ 开始，deploy.resources 在 docker compose up（非 Swarm）下也已原生支持。
用 deploy.resources 限制 CPU 和内存（推荐主用）
这是生产环境首选方式，语义清晰、跨平台、无需额外运维干预：
-
CPU 限制：用
cpus: "0.75"表示最多使用 0.75 个逻辑核心（即 75% 单核时间或等效多核配额），底层映射为 cgroup v2 的cpu.max = 75000 100000 -
内存硬限制：用
memory: "1G"对应memory.max，超限触发 OOM Killer，容器被强制终止 -
内存软预留：用
reservations.memory: "512M"影响memory.low（仅 cgroup v2 有效），调度时优先保障，但不保证绝对可用 -
PID 数量限制：Compose v2.23+ 支持
limits.pids: 200，防止 fork 爆炸类攻击
按服务差异化配额（实战常见组合）
不同角色的服务应有不同资源策略。例如 Web 前端轻量、数据库重载、后台任务间歇性高消耗：
-
API 服务：
limits: {cpus: "0.5", memory: "512M"}+reservations: {cpus: "0.2", memory: "256M"}—— 控制突发负载，保留基础响应能力 -
PostgreSQL：
limits: {cpus: "2", memory: "4G"}+reservations: {memory: "2G"}—— 保证缓冲区稳定，避免频繁 swap -
Worker 任务容器：可设更高
cpus但搭配mem_reservation低值，让它“尽力而为”，不抢占关键服务资源
验证配置是否生效
容器启动后，无需进容器即可快速确认：
- 查宿主机对应 cgroup 路径：
cat /sys/fs/cgroup/docker/$(docker inspect -f '{{.Id}}' )/cpu.max - 查内存上限：
cat /sys/fs/cgroup/docker/$(docker inspect -f '{{.Id}}' )/memory.max - 用
docker stats实时观察实际使用率，对比 limits 值是否形成压制
慎用 runtime_opts（仅限新环境高级调试）
若你明确运行在 Docker 24.0+、cgroup v2、且启用实验特性，才考虑用 runtime_opts 写入底层参数：
- 添加 label：
"com.docker.compose.runtime_opts=cpu.weight=300 memory.high=1073741824" - 这会直接写入
/sys/fs/cgroup/<path>/cpu.weight</path>和memory.high，前者影响 CPU 调度权重，后者是 soft limit（触发回收但不 kill） - ⚠️ 注意：该功能不稳定，Docker CLI 未提供统一校验机制，线上环境建议回避
