docker容器资源限制的底层支撑是linux内核cgroups机制：namespace实现隔离（“看不见”），cgroups实现资源限制（“用不了”）；cpu靠cpu子系统配额节流，内存靠memory子系统设硬上限防oom，i/o和进程数分别由blkio与pids子系统管控，v2统一层级提升可靠性。
docker 容器资源限制的底层支撑，是 linux 内核的 cgroups（control groups） 机制。它不是 docker 自研功能，而是内核原生提供的资源分组管理框架——namespace 负责“看不见”，cgroups 负责“用不了”。没有 cgroups，容器就只是隔离的进程，谈不上资源可控。
CPU 限制：靠 cpu 子系统实现时间片调度
cgroups 的 cpu 子系统通过两个关键参数控制 CPU 使用量：
- cpu.cfs_period_us：调度周期，默认 100000 微秒（即 100ms）
- cpu.cfs_quota_us：该周期内允许使用的 CPU 时间上限（微秒）
比如 --cpus=0.5，Docker 实际写入的是 cpu.cfs_period_us=100000 和 cpu.cfs_quota_us=50000，表示每 100ms 最多运行 50ms，等效于半个 CPU 核心。若设为 --cpus=2.3，则配额为 230000 微秒。注意：这个限制是硬性上限，超限后进程会被内核节流，不会被杀死。
内存限制：memory 子系统防止 OOM 和系统崩溃
memory 子系统通过 memory.limit_in_bytes 文件设定容器内存硬上限。例如 --memory=512m，Docker 会将 536870912（512×1024×1024）写入对应 cgroup 的该文件。
当容器内存使用逼近该值时：
- 内核会尝试回收 page cache、swap 等可释放内存
- 若仍无法满足分配请求，触发 OOM Killer，优先杀死容器内消耗内存最多的进程
- 该行为由
memory.oom_control控制，Docker 默认启用
补充说明：--memory-swap 控制总虚拟内存（RAM + swap），设为 0 表示禁用 swap，设为与 --memory 相同值表示完全禁用 swap。
使用 Python 脚本下载 Docker 镜像并打包为 tar 文件。用户说“下载镜像”“拉取镜像”“pull xxx”“帮我下载 nginx 镜像”等时触发。支持 SOCKS5 代理直连（推荐）和国内镜像站加速两种模式。
I/O 与进程数限制：blkio 和 pids 子系统协同管控
磁盘 I/O 限制依赖 blkio 子系统。Docker 使用 --device-read-bps 或 --device-write-bps 参数时，会在对应设备的 blkio 控制组中设置 blkio.throttle.read_bps_device 等文件，实现字节级带宽硬限速。
进程数量限制由 pids 子系统完成。--pids-limit=100 会写入 pids.max = 100，一旦容器内活跃进程数达到上限，fork() 系统调用将直接返回 EAGAIN 错误，新进程无法创建——这对防范 fork bomb 类攻击非常关键。
cgroups v1 与 v2：统一层级带来更可靠的行为
旧版 cgroups v1 各子系统独立挂载（如 /sys/fs/cgroup/cpu、/sys/fs/cgroup/memory），易出现配置不一致或冲突。而 cgroups v2 采用单挂载点（默认 /sys/fs/cgroup），所有资源控制器在统一层级下协同生效。
Docker 自 20.10 版本起默认支持 cgroups v2，优势明显：
- 避免 memory 和 cpu 子系统不同步导致的资源误判
- 支持更精细的嵌套控制（如容器内再建子组）
- 统一接口简化运维，例如所有限制都通过
cgroup.procs加入进程
可通过 cat /proc/1/cgroup 查看当前是否运行在 v2 模式：若第一行含 0::/，即为 v2；若含多行如 8:devices:/、7:memory:/，则是 v1。
