结论：单机模式下deploy.resources不生效，应改用顶层mem_limit和cpus字段——前者设内存硬限制防宿主机崩溃，后者配CPU时间片保服务响应，配合restart与healthcheck实现稳定存活。
直接说结论：在单机模式下，deploy 字段的资源限制（如 resources.limits）默认不生效。它只对 docker stack deploy（即 Swarm 模式）起作用。但你仍可以通过组合配置 + 系统级手段，让单机应用在资源过载时“有底线地存活”——关键不是依赖 deploy，而是用对等、兼容且实际生效的方式替代。
明确哪些 deploy 配置在单机下真正有用
虽然 deploy.resources 在 docker-compose up 中被忽略，但以下子项仍可部分生效或提供间接保障：
-
restart_policy：Swarm 专属字段，但在单机中会被降级为容器级重启逻辑（需配合
restart字段更可靠） - resources.reservations：完全不生效——单机无调度器，无法预留
- resources.limits：完全不生效——除非你启用 experimental 的 compose v2.20+ 的 “compose up with swarm mode” 开关，否则底层不调用 cgroups 限流
单机下真正管用的资源控制方式
要让服务在内存爆满、CPU打满时不崩溃或拖垮整台机器，必须绕过 deploy，改用 Compose 支持的原生命令级参数：
-
mem_limit：硬性内存上限，超限触发 OOM Killer 杀该容器（不是宿主机），例如mem_limit: 512m -
cpus：限制 CPU 时间配额（基于 cgroups cpu.shares 和 cpu.cfs_quota_us），例如cpus: '0.75' -
mem_reservation：软性内存预占（仅在支持的 Docker 版本中影响 OOM 评分，非强保证） -
oom_score_adj：手动调低该容器被 OOM Killer 选中的优先级，保护关键服务（如设为 -500）
示例片段：
minimax-mcp-docker版（适配极空间）
下载
MiniMax 图片理解 + 网络搜索 MCP 工具。适配 Docker 环境（极空间等），支持图片 OCR 识别、图像内容理解、网络搜索。API Key 安全存储在本地 credentials 文件，不暴露在代码中。
services:
api:
image: myapp:latest
mem_limit: 768m
cpus: '0.8'
oom_score_adj: -300
restart: on-failure:3
配套加固：让“存活”不只是不退出
光限制资源不够，还要确保服务在压力下仍能响应基本请求、不雪崩：
- 在应用内嵌健康检查（如
healthcheck字段），避免负载均衡把流量导给卡死的实例 - 用
ulimits限制文件描述符、线程数，防住内部资源耗尽（如nproc: 2048） - 配合宿主机监控（如 ctop、docker stats）设置告警，在内存达 85% 时人工干预或自动缩容
为什么不建议强行在单机启用 deploy.resources
有人尝试加 --compatibility 或升级到最新 Docker Desktop 并开启 Swarm 单节点模式来“骗过”限制——可行但不推荐：
- 引入 Swarm daemon 开销，增加故障面
- stack deploy 启动的服务无法用
docker-compose logs直接查日志 - 本地开发调试链路变长，与 CI/CD 环境行为不一致
真正稳定的单机资源防护，是用 mem_limit + cpus + restart + healthcheck 这四件套，轻量、确定、全版本兼容。
