deploy字段在单机docker compose中不生效，应改用mem_limit、cpus、ulimits和healthcheck组合实现资源控制与服务韧性。
deploy 字段在单机 Docker Compose（即 docker-compose up）中不生效，这是关键前提。它专为 Docker Swarm 集群设计，所有 deploy 下的配置（包括 replicas、placement、update_config，甚至大部分 resources）在单机模式下会被完全忽略。
但你的问题聚焦于「单机应用在资源过载下的安全存活」——这确实是个高频痛点。虽然 deploy.resources 不起作用，仍有可靠、直接、无需 Swarm 的方式实现资源控制与服务韧性。核心思路是：绕过 deploy，改用 Compose 顶层或容器级原生命令参数，结合 Linux cgroups 机制生效。
以下是真正有效的三类做法，按优先级和实用性排序：
直接使用 mem_limit 和 cpus 顶级字段（最推荐）
这些是 Compose v2.4+ 原生支持的单机资源限制字段，无需 Swarm，docker-compose up 即刻生效，底层直通 docker run --memory 和 --cpus。
version: '3.8'
services:
web:
image: nginx:alpine
mem_limit: 512m # 硬内存上限，超限触发 OOM Killer
cpus: 0.75 # 最多占用 0.75 个 CPU 核心（等价于 --cpus=0.75）
mem_reservation: 256m # 软预留，影响调度感知（部分版本支持，非强制保障）
✅ 优势：
- 配置简洁，语义清晰，兼容所有现代 Docker Desktop 和 Linux Docker 引擎
-
mem_limit触发内核 OOM Killer，防止内存耗尽拖垮整机 -
cpus基于 CFS quota，严格限制 CPU 时间片，避免 CPU 饱和
⚠️ 注意：
-
mem_reservation在单机模式下仅作提示，不保证资源预留（无调度器参与），实际效果弱；重点依赖mem_limit+cpus - 内存单位区分大小写：
512m✅，512M❌（Compose 解析可能失败）
补充：用 ulimits 控制进程级资源（防崩溃扩散）
当应用自身存在 fork 爆炸、文件句柄泄漏、线程失控等问题时，仅限 CPU/内存不够。ulimits 可设硬性系统级约束：
services:
api:
image: python:3.11-slim
ulimits:
nofile: # 文件描述符
soft: 1024
hard: 4096
nproc: 512 # 最大进程/线程数
as: 1073741824 # 地址空间上限（bytes ≈ 1GB）
✅ 效果：
-
nproc可阻止 Pythonmultiprocessing或 JavaForkJoinPool无限创建线程导致系统卡死 -
nofile防止“Too many open files”引发服务假死或日志丢失
必配：健康检查 + 重启策略（提升存活率）
资源过载常伴随响应变慢、连接超时、进程僵死。仅靠资源限制不够，需主动探测并恢复：
services:
web:
image: nginx:alpine
mem_limit: 512m
cpus: 0.75
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost:80/health"]
interval: 30s
timeout: 5s
retries: 3
start_period: 40s
restart: on-failure:5 # 连续失败5次后停止，避免疯狂重启打满日志
✅ 价值：
- 健康检查失败 → 容器被标记 unhealthy → 外部负载均衡（如 Traefik）自动剔除流量
-
on-failure:5防止因内存不足反复重启却无法恢复的“抖动陷阱”
不复杂但容易忽略：单机环境请彻底放弃对 deploy.resources 的依赖。mem_limit、cpus、ulimits 和 healthcheck 四者组合，已足够在绝大多数资源过载场景下守住服务底线——既防拖垮宿主机，也保自身可恢复。
