Composer在容器中构建慢主因是镜像源未换、配置错误、插件残留或缓存未清；需确认版本≥2.1、禁用hirak/prestissimo、设http-max-concurrent-downloads为8、Dockerfile中同步换源并clear-cache，且GitHub直链需Token或改用Gitee。
Composer 在容器中构建慢，不是因为没开并发，而是并发根本没跑起来——镜像源没换、配置写错、插件残留、缓存没清，四者占了 90% 的“假慢”原因。
确认 Composer 版本是否真支持并行下载
低于 2.1 的版本压根不支持原生并行，parallel-downloads 和 http-max-concurrent-downloads 都是摆设。必须先验证：
- 运行
composer --version，输出必须是Composer version 2.1.x或更高（如2.9.6） - 若版本偏低，执行
composer self-update --prefer-dist - 若
composer diagnose提示hirak/prestissimo，立刻运行composer global remove hirak/prestissimo—— 这个插件在 2.1+ 下会静默降级为串行，还可能破坏composer.lock
只用 http-max-concurrent-downloads，别碰 parallel-downloads
parallel-downloads 在 2.2+ 中已被官方弃用，设了也不生效；真正起作用的只有 http-max-concurrent-downloads，它控制 HTTP 请求池大小，直接影响 composer install 阶段的并发能力。
OpenClaw Docker Setup
下载
在 Linux 上通过 Docker 运行 OpenClaw，并使用 Tailscale 实现远程访问。⚠️ 涉及 sudo、Docker、Tailscale和凭证挂载——请先查阅安全章节...
- 全局设为
8（多数容器环境的稳态上限）：composer config -g http-max-concurrent-downloads 8 - 值不是越高越好：设成
12以上容易触发阿里云/腾讯云镜像的429 Too Many Requests，或引发file_put_contents(/tmp/): failed to open stream（临时文件竞争） - 该配置对
composer update无效——元数据拉取（如packages.json）仍是串行，这是设计限制，不是配错了
Docker 构建中必须同步完成三件事
容器里并发失效，往往是因为构建步骤没对齐 Composer 的缓存与网络机制：
- 先复制
composer.json和composer.lock，再执行安装命令，确保依赖层能被 Docker 缓存复用 - 换源命令必须写进
Dockerfile，不能靠宿主机配置：RUN composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 换源后必须立刻清缓存：
RUN composer clear-cache，否则旧缓存里的境外元数据仍会回源请求 - CI 环境建议加
--no-interaction --no-progress，避免进度条锁住输出缓冲导致并发线程阻塞
并发再快，也救不了 GitHub 直链和未授权访问
很多项目在容器里卡住，不是并发没开，而是某些包硬编码了 GitHub URL（比如 "dist": {"url": "https://github.com/xxx/yyy/archive/..."}），这类请求绕过镜像，直击 GitHub API，极易触发限流。
- 检查错误日志是否含
GithubRateLimitException或403 rate limit exceeded - 补 GitHub Token：
composer config -g github-oauth.github.com YOUR_TOKEN（Token 在 GitHub Settings → Developer settings → Personal access tokens 生成） - 若无法配 Token，可 fork 到 Gitee 并改
composer.json指向 Gitee zip 地址（需 tag 一致） - 注意：镜像源只加速 Packagist 元数据和 dist 包分发，对这类手动写的 GitHub 链接完全无效——这点最容易被忽略，一卡就是十分钟
