Docker Compose中重启策略由restart字段控制，含no/always/on-failure/unless-stopped四种取值；资源限制必须通过deploy.resources配置，含limits（硬上限）和reservations（软预留），且仅在Swarm模式下生效。
在 Docker Compose 中配置重启策略和资源限制，核心在于正确使用 restart 和 deploy.resources 两个字段。这两类配置作用不同：重启策略控制容器生命周期的恢复行为，资源限制则约束其运行时对 CPU、内存等系统资源的占用。它们都需写在服务（service）层级下，且部分参数仅在 Swarm 模式生效。
重启策略的四种取值与适用场景
重启策略通过 restart 字段设置，共支持四种取值，行为差异明确：
- no：默认值，容器退出后不自动重启。适合调试容器、一次性脚本或数据库迁移等不可重入任务。
- always：无论退出码是 0 还是非 0，只要容器停止就立即重启。适用于 Web 服务器、API 网关等长期在线服务。
-
on-failure：仅当容器以非零退出码退出时重启。可加次数限制，如
on-failure:3表示最多重试 3 次。适合批处理作业或后台 worker，避免失败循环拉起。 -
unless-stopped：除被手动执行
docker stop外，其他所有退出（包括宿主机重启、守护进程恢复）都会触发重启。适合数据库、缓存等需持久运行但允许人工干预的服务。
资源限制必须用 deploy.resources 配置
资源限制只能在 deploy.resources 下定义，且仅对 docker stack deploy 生效，docker-compose up 会忽略这些设置。它包含两组关键子项：
-
limits：硬性上限，容器绝不可突破。例如
cpus: '1.0'表示最多使用 1 个完整 CPU 核心；memory: 512M表示内存上限为 512MB。 -
reservations：软性预留，调度器保证容器启动时至少能获得该资源。例如
cpus: '0.5'和memory: 256M可防止服务因资源争抢而无法启动。
注意：CPU 单位支持小数（如 '0.25'），内存单位支持 B、K、M、G；memory_swap 可单独设为 limits.memory 的 1.5 倍左右，用于控制总虚拟内存上限。
其他实用资源控制参数
除基础 limits/reservations 外，还可配合以下参数增强稳定性：
-
cpuset：指定容器可绑定的 CPU 核心编号，如
"0-2"或"0,2,4"，适用于 NUMA 架构或性能隔离场景。 -
memswap_limit：设定内存 + swap 总量上限，必须 ≥
mem_limit。例如mem_limit: 300M+memswap_limit: 1G表示最多使用 300MB 物理内存和 700MB swap。 -
oom_kill_disable：设为
true时，内存超限时内核不杀容器，而是尝试 kill 容器内进程来回收内存（慎用，可能引发僵死状态）。 - oom_score_adj：调整容器被 OOM killer 选中的优先级，范围 -1000（最不易被杀）到 1000（最优先被杀），默认为 0。
验证配置是否生效
部署后可通过命令确认实际生效的限制：
- 查看容器详细信息：
docker inspect <container_id> | grep -A 5 -i "nano\|memory\|cpuset" - CPU 显示为
NanoCpus（1 核 = 1000000000 纳秒/秒），内存显示为字节数，CpusetCpus显示绑定核心。 - 若使用 Swarm，还可通过
docker service ps <service_name>查看调度状态和资源分配结果。
