Docker可通过运行时参数直接限制CPU和内存：--cpus设硬上限（如1.5核），--cpu-shares设相对权重（默认1024），--cpuset-cpus绑定指定核心；内存须配-m设物理上限（如512m）和--memory-swap控总内存+swap（建议同值以禁用swap），避免OOM。
直接用 Docker 提供的运行时参数就能限制容器的 CPU 和内存，不需要额外工具或修改镜像。关键不是“能不能限”，而是选对参数、设合理值——否则可能压垮服务，也可能白白浪费资源。
CPU 限制：三种方式，用途不同
限制 CPU 不是只有一种方法，得看你要解决什么问题：
-
--cpus：硬性上限，最常用。比如
--cpus=1.5表示容器最多用 1.5 个逻辑 CPU 核心的算力（支持小数）。适合对计算资源敏感的应用，如 Web 服务、API 网关。 -
--cpu-shares：相对权重，默认 1024。比如两个容器分别设为
--cpu-shares=2048和--cpu-shares=1024，当 CPU 满载时，前者能拿到约两倍的 CPU 时间。但空闲时它也能跑满；只在争抢时生效。 -
--cpuset-cpus：绑定具体核心，比如
--cpuset-cpus="0,2"表示只允许在 CPU 0 和 CPU 2 上运行。适合需要缓存亲和性或隔离关键任务的场景（如数据库、实时计算）。
内存限制：必须设硬上限，还要管 Swap
内存没限制风险最高——超了直接被 OOM Kill，容器退出，服务中断。所以至少要配两个参数：
-
-m 或 --memory：物理内存硬上限，比如
-m 512m。超过这个值，内核会杀掉容器里最耗内存的进程。 -
--memory-swap：内存 + Swap 的总上限。如果只设
-m 512m而不设 swap，Docker 默认允许再用 512m Swap（共 1G），这可能导致磁盘 IO 暴增、响应变慢。生产环境建议设成跟 memory 相同，比如--memory-swap 512m，等于禁用 Swap。 - 可选加 --memory-reservation：软限制，比如
--memory-reservation 256m。当宿主机内存紧张时，Docker 会优先从这类容器回收内存，但它平时仍可用到 512m。
Docker Compose 里怎么写
在 docker-compose.yml 中统一管理更可靠，尤其多服务部署时：
version: '3.8'
services:
api:
image: my-api:latest
deploy:
resources:
limits:
cpus: '1.2'
memory: 768M
reservations:
cpus: '0.5'
memory: 256M
注意：limits 是硬上限，reservations 是预留量（类似最低保障），两者都填更稳妥。这个配置只在 Swarm 模式下完全生效；单机用 docker-compose up 时，limits 依然有效，reservations 会被忽略。
验证和调优不能跳过
设完不验证等于没设：
- 查实时使用：
docker stats <容器名>，看 CPU % 和 MEM USAGE 是否卡在预期范围内。 - 查 cgroup 设置：
docker exec <容器名> cat /sys/fs/cgroup/memory/memory.limit_in_bytes，确认数值是否准确写入。 - 压测验证：进容器跑
stress-ng --cpu 4 --timeout 30s，观察是否被限频或 OOM；别等上线后出事才试。
