默认并发下载数为3，控制镜像layer拉取数量；推荐设为5–20，需通过修改daemon.json并重启docker生效，同时注意registry端限流限制。
安装完 Docker 后，默认并发下载数是 3，它控制的是同时拉取的镜像 layer 数量，不是单个 layer 内部的分块并发，也不是整体带宽开关。这个值偏低，尤其在内网高速环境或私有 Registry（如 Harbor）中，常成为拉取瓶颈。
修改 /etc/docker/daemon.json 配置文件
这是最常用、最稳妥的方式：
- 用文本编辑器打开配置文件：sudo vim /etc/docker/daemon.json
- 添加或修改 max-concurrent-downloads 字段，例如设为 10：
{"max-concurrent-downloads": 10}
推荐范围是 5–20；超过 50 很少带来收益，反而易触发 registry 限流或 TLS 握手堆积 - 若文件为空或不存在，直接写入完整 JSON 对象（确保语法合法，末尾无逗号）
重启 dockerd 守护进程使配置生效
配置只在守护进程启动时读取，必须重启才能应用：
- 执行：sudo systemctl restart docker
- 验证是否加载成功：docker info | grep "Max Concurrent Downloads"
- 如果输出类似
Max Concurrent Downloads: 10，说明已生效；若提示unknown configuration key，说明 dockerd 版本低于 20.10，需升级
注意 registry 端的实际限制
客户端调高并发，不代表实际请求能全部跑满：
- Harbor 默认匿名请求限 5 QPS，登录后升至 50；需检查
harbor.yml中的rate_limits - AWS ECR 按出口 IP 统计，上限约 16 RPS；多台 Worker 共用一个公网 IP 时极易触发 429 错误
- 遇到
error pulling image configuration: unknown blob或日志频繁出现 429，优先查 registry 监控，而非继续调高 client 并发
--platform 参数会间接影响并发效果
显式指定平台（如 --platform linux/arm64）会改变 manifest 解析逻辑：
- 可能命中不同架构的子 manifest，导致 layer 数量、大小、依赖关系变化
- 原本不拉的 layer 变成要拉，或拉取顺序与大小分布发生偏移，实际并发请求数和负载分布随之改变
- 有时总耗时反而上升——不是并发没起作用，而是下载任务本身变复杂了
