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"</container_id>
• CPU 显示为 NanoCpus（1 核 = 1000000000 纳秒/秒），内存显示为字节数，CpusetCpus 显示绑定核心。
• 若使用 Swarm，还可通过 docker service ps <service_name></service_name> 查看调度状态和资源分配结果。