--cpus和--memory是Docker中唯一能实现CPU与内存硬上限的参数，前者基于CFS配额节流，后者超限触发OOM Kill；其他如--cpu-shares或--memory-reservation仅为软限制，不构成强制约束。
直接限制 CPU 和内存上限，必须用 --cpus 和 --memory，其他参数（比如 --cpu-shares 或 --memory-reservation）不构成硬性上限，超了也不会被杀。
用 --cpus 限制 CPU 核心数，不是“百分比”
很多人误以为 --cpus=0.5 是“限制 CPU 使用率到 50%”，其实它表示“最多使用 0.5 个逻辑 CPU 核心的计算时间”。在 4 核机器上，这个容器最多能跑满半个核，不会抢走其他容器的调度份额。
-
--cpus是硬限制，基于 CFS 的cpu.cfs_quota_us实现，超了就 throttled（被节流），进程不会卡死但会明显变慢 - 不要混用
--cpus和--cpu-shares：前者管绝对上限，后者只在争抢时起作用，单独设--cpu-shares=512对单容器完全无效 - 如果宿主机是单核，
--cpus=1.5会被自动截断为 1.0；小数只在多核下有意义 - 绑定特定核心要用
--cpuset-cpus（例如--cpuset-cpus="0,2"），和--cpus是正交配置，可同时用
用 --memory 设硬上限，超了直接 OOM Kill
--memory（或简写 -m）才是真正生效的内存硬限制。一旦容器内进程申请内存超过该值，Linux 内核会触发 OOM Killer，随机选一个进程干掉——通常是主进程，容器随即退出，状态变成 Exited (137)。
在 Linux 上通过 Docker 运行 OpenClaw，并使用 Tailscale 实现远程访问。⚠️ 涉及 sudo、Docker、Tailscale和凭证挂载——请先查阅安全章节...
- 必须配
--memory-swap：如果不设，Docker 默认允许使用等量 swap（即总内存上限 = 2 ×--memory）。想彻底禁用 swap，得显式写--memory-swap=512m（和--memory值一致） -
--memory-reservation是软限制，仅当系统内存紧张时才尝试压缩，不能防 OOM - 单位要写对：
512m、2g、1024M都合法，但512mb或512Mib会报错 - 实际可用内存略小于设定值：cgroup 开销、内核页表等会占用几 MB，别卡着 512m 给一个刚好吃 512m 的 Java 应用
docker-compose.yml 里怎么写才真正生效
在 docker-compose.yml 中，资源限制必须放在 deploy.resources.limits 下，且仅在 docker stack deploy（Swarm 模式）或 docker compose up（v2.20+）中被识别。旧版 docker-compose up 会静默忽略这些字段。
- 正确写法：
version: '3.8' services: api: image: myapp deploy: resources: limits: cpus: '1.2' memory: 1G # 注意：memswap_limit 不在 limits 下，而是单独字段（v3.8+ 支持） reservations: memory: 512M -
cpus必须是字符串（带引号），否则 YAML 解析器可能转成浮点数导致失败 -
mem_limit这种老写法已废弃，只在docker run里支持，compose 中无效 - 如果用
docker-compose up但没生效，先检查 CLI 版本：docker compose version，低于 v2.20 的需升级或改用docker run
最易被忽略的一点：--cpus 和 --memory 是独立生效的，但它们共同依赖宿主机的 cgroups v1/v2 支持。如果你在 WSL2 或某些嵌入式 Linux 上运行，cgroup2 可能未启用，此时 --cpus 会降级为 --cpu-shares 行为——看起来限制了，其实没硬控住。验证方式是进容器执行 cat /sys/fs/cgroup/cpu.max（cgroup v2）或 cat /sys/fs/cgroup/cpu/cpu.cfs_quota_us（v1），看输出是否匹配你设的值。
