Composer不存在代理网关缓存预热机制，其每次安装或更新均按需发起独立HTTP请求，不复用连接、不主动预加载；所谓“预热”实为对镜像源缓存行为的误解。
Composer根本不存在代理网关缓存预热
“代理网关缓存预热”是把数据库或 CDN 场景的概念硬套到 Composer 上造成的误解。Composer 没有、也不会实现 HTTP 缓存代理（如 Squid）、连接池或主动预加载元数据的机制。它每次执行 composer install 或 composer update，都是按需发起独立 HTTP 请求，不复用连接句柄，也不提前拉取未被请求过的包。
- 所谓“预热”，实际是误读了镜像源的缓存行为：镜像（如阿里云、腾讯云）只缓存已被
composer require或install触发下载过的包，不会全量同步或定时刷热 - 元数据（
packages.json）更新有 5–30 分钟延迟，新发布的包在镜像上查不到是正常现象，不是“没预热” - 如果你看到命令卡在
Downloading阶段，大概率是镜像 URL 少了末尾/、没启用ext-curl、或当前用户没配镜像源，而非“缓存未就绪”
真正该做的“暖配置”和“暖环境”
不是预热缓存，而是确保每次运行时 Composer 能走最短路径、用最优参数完成任务：
- 全局设镜像源：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/（注意末尾/） - 对每个执行用户单独配置：CI 中用
sudo -u www-data composer config -g ...，别只在 root 下跑一遍 - 构建脚本开头加环境变量：
COMPOSER_NO_INTERACTION=1 COMPOSER_MEMORY_LIMIT=-1，避免交互阻塞和内存中断 - 启用 OPcache：
php -d opcache.enable=1 $(which composer)，加速 Composer 自身解析逻辑
缓存目录才是你唯一的“热备中心”
~/.composer/cache/ 是 Composer 唯一真正意义上的本地热备——只要不手动清空或删掉它，重复安装同一依赖会直接复用已下载的 .zip 文件，毫秒级完成。
- 确认位置：
composer config cache-dir - 查看大小：
du -sh $(composer config cache-dir)（积压后常达 2–5GB） - 迁移到 SSD 可显著提升多项目构建速度；但别 symlink 到
/tmp，CI 环境可能定期清理 - 关键配置项：
cache-files-ttl（默认 6 个月）、cache-files-maxsize（默认 300MiB），可写进~/.composer/config.json控制自动 GC
镜像源和 HTTP 代理不可共存
很多人试图同时配 http-proxy 和 repo.packagist 镜像，结果命令卡死或静默失败。这两者底层机制冲突：
- 镜像源是直连独立站点（如
https://mirrors.tencent.com/composer/），不经过本地代理 - HTTP 代理（
http-proxy/https-proxy）仅用于绕过网络限制，且必须同时配置、协议必须为http:// - 一旦设了镜像源，就该清掉旧的代理配置，否则可能干扰 DNS 解析或触发 TLS 不匹配
- 带认证的代理 URL 必须对密码做
rawurlencode()，否则@或:会导致 URI 解析失败
复杂点在于：Composer 的并发只作用于下载阶段，依赖解析永远单线程。再快的镜像、再多的并发，也救不了一个含 200+ 包、带复杂版本约束的 composer.json。这时候，与其折腾“预热”，不如精简 require-dev、拆分 monorepo 或引入私有包白名单机制。
