CPU限制推荐用--cpus设硬上限（如1.5核），内存必须设--memory硬限制（如512m）防OOM，Docker Compose中通过deploy.resources统一配置limits和reservations更可靠。
直接在运行容器时加参数就能生效，关键不是“能不能设”，而是“设多少才合理”。CPU 和内存限制必须分开考虑，因为它们的机制和风险完全不同。
CPU 限制：两种思路，适用不同场景
CPU 限制本质是控制时间片分配，不是物理核心绑定（除非你主动用 --cpuset-cpus）。日常最实用的是以下两种方式：
- --cpus=1.5：硬性上限。容器最多使用 1.5 个逻辑 CPU 核心的计算能力，无论宿主机是否空闲。适合对响应延迟敏感、资源需求可预测的服务，比如 API 网关或数据库代理。
- --cpu-shares=512：相对权重。默认值是 1024，数值只在多个容器同时争抢 CPU 时起作用。比如一个设 2048、一个设 1024，前者会分到约两倍的 CPU 时间；但若后者没活干，前者可以跑满整机 CPU。适合后台任务或低优先级批处理。
不建议混用 --cpus 和 --cpu-shares，容易造成策略冲突。生产环境推荐优先用 --cpus，逻辑清晰、行为确定。
内存限制：必须设硬上限，否则有 OOM 风险
内存不像 CPU 可以“借”，超了就会被内核强制杀死（OOM Kill），容器状态变为 Exited。所以 --memory 是必选项：
- -m 512m：容器最多使用 512MB 物理内存。超过立即触发 OOM。
- --memory-swap 1g：内存 + swap 总量不超过 1GB。若只设 -m 未设 --memory-swap，Docker 默认允许使用等量 swap（即总共最多 1GB）；设为与 -m 相同值（如 -m 512m --memory-swap 512m），表示禁用 swap。
- --memory-reservation 256m：软限制。宿主机内存充足时容器可用更多，但当整体紧张时，系统会优先压缩这个容器的内存占用到 256MB 以内。
典型组合：-m 1g --memory-swap 1g（禁用 swap，避免磁盘抖动）+ --memory-reservation 512m（预留缓冲空间）。
Docker Compose 中统一管理更可靠
命令行容易漏配或写错，推荐在 docker-compose.yml 的 deploy.resources 下集中定义：
- limits 下写硬性上限：
cpus: '1.5'、memory: 1G - reservations 下写保障下限（调度器据此安排容器部署）：
cpus: '0.5'、memory: 512M
这样既防止资源过载，又让 Swarm 或 Kubernetes 类平台能做更合理的节点调度。
验证是否生效，不能只看启动命令
容器跑起来后，用 docker stats <容器名> 实时查看 CPU% 和 MEM USAGE / LIMIT；再进容器执行 cat /sys/fs/cgroup/memory/memory.limit_in_bytes 或 cat /sys/fs/cgroup/cpu/cpu.cfs_quota_us，确认内核层面的 cgroup 值已按预期写入。没看到对应数值，说明限制根本没生效。
