能，但需查 HostConfig.CpuQuota 和 HostConfig.CpuPeriod 字段；整数 --cpus 值可能显示为 HostConfig.CpuCount，小数则转为 CpuQuota/CpuPeriod 比值，如 150000/100000 表示 --cpus=1.5。
docker inspect 能直接看到 --cpus 配置吗
能，但要看字段位置。Docker Desktop（基于 Linux 后端或 WSL2）和原生 Linux 的行为一致：docker inspect 输出里，HostConfig.CpuCount 字段只在使用 --cpus 且值为整数时出现；小数（如 --cpus=1.5）则不会写入该字段，而是转为 CpuQuota 和 CpuPeriod。
更可靠的方式是查这两个字段：
-
HostConfig.CpuQuota：非零值表示启用了 CFS 配额限制（单位微秒） -
HostConfig.CpuPeriod：默认100000（即 100ms），若被显式修改需一并看
比如 "CpuQuota": 150000, "CpuPeriod": 100000 就等价于 --cpus=1.5。
在容器内部怎么验证 CPU 限制是否生效
进容器后不能靠 lscpu 或 /proc/cpuinfo 看“可用核心数”——这些显示的是宿主机全部逻辑 CPU，跟限制无关。真正反映限制的是 cgroup v2 的 /sys/fs/cgroup/cpu.max（推荐）或 cgroup v1 的 /sys/fs/cgroup/cpu/cpu.cfs_quota_us。
执行以下命令即可确认：
-
cat /sys/fs/cgroup/cpu.max→ 输出类似150000 100000表示 quota/period，换算为150000 ÷ 100000 = 1.5 -
cat /sys/fs/cgroup/cpu/cpu.cfs_quota_us（v1）和cpu.cfs_period_us→ 含义同上 - 如果输出是
max，说明没设任何 CPU 限制
注意：这些路径需要容器以默认的 cgroup 模式运行（不是 --cgroup-parent 自定义），且不挂载 /sys/fs/cgroup 覆盖。
docker stats 显示的 CPU% 是怎么算的，它受 --cpus 影响吗
受，但不是硬性截断。docker stats 的 CPU% 是「该容器在过去一秒内实际使用的 CPU 时间 ÷ 所有可用 CPU 核心总时间 × 100%」。比如宿主机是 4 核，1 秒理论最多 400%，而 --cpus=1.5 的容器在资源争抢时，其 CPU% 通常不会超过 150%（1.5 × 100%）。
但要注意几个现实情况：
- 空闲时它可能飙到接近 400%，因为
--cpus是软限制，不是预留 - 如果宿主机只有 2 核，
--cpus=1.5实际上限就是 150%，docker stats的峰值会卡在 150% 左右 - Windows/macOS 上 Docker Desktop 用的是虚拟机层（WSL2 或 HyperKit），
docker stats显示的是 VM 内部视角，和宿主机 top 不完全对得上
docker-compose.yml 里 cpus: '1.2' 为什么必须加引号
YAML 规范里，1.2 默认被解析为浮点数，但 Docker Compose 的 deploy.resources.limits.cpus 字段要求是字符串类型。不加引号会导致解析失败或静默忽略 —— 容器启动后 docker inspect 查不到任何 CPU 限制字段，docker stats 也完全不受控。
实操验证方法：
- 写成
cpus: 1.2（无引号）→docker compose up启动后执行docker inspect | grep -E "(CpuQuota|CpuCount)"，输出为空 - 写成
cpus: '1.2'或cpus: "1.2"→ 同样命令能看到CpuQuota值
这个细节在 CI/CD 流水线或多人协作中极易被忽略，建议统一加单引号并加入 pre-commit 钩子校验。
