不建议建“全量热备中心”，而应聚焦于镜像代理 + 本地缓存组合方案——既解决下载慢、失败多的问题，又避免全量同步带来的存储爆炸、元数据滞后和维护黑洞。
直接说结论：不建议建“全量热备中心”，而应聚焦于镜像代理 + 本地缓存组合方案——既解决下载慢、失败多的问题，又避免全量同步带来的存储爆炸、元数据滞后和维护黑洞。
为什么 composer install 总卡在 packagist.org 或报 Connection refused
国内直连 Packagist 官方源（https://packagist.org）常因 DNS 污染、TLS 握手超时或 CDN 节点不可达导致失败。这不是 Composer 本身问题，而是网络路径受阻。官方镜像（如腾讯、阿里、华为）本质是反向代理 + 缓存，不是独立数据库，不会主动拉取全量包。
- 镜像只缓存被实际请求过的包（
composer require foo/bar触发后才拉） - 镜像不提供
packages.json全量快照，因此无法支持离线composer update --prefer-dist - 镜像元数据更新有延迟（通常 5–30 分钟），新发布的包可能查不到
用 composer config 切换镜像源比改 repositories 更安全
手动在 composer.json 里写死 repositories 会覆盖全局配置，且容易误删 packagist.org 的 fallback 行为；而 composer config 修改的是 ~/.composer/config.json 或项目级 composer.json 的 config.repo.packagist 字段，保留了 Composer 的自动降级逻辑。
- 全局切换（推荐）：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 项目级切换（CI/CD 场景）：
composer config repo.packagist composer https://mirrors.tencent.com/composer/ - 验证是否生效：
composer config repo.packagist应返回镜像 URL，而非{"type": "composer", "url": "..."}这类对象
composer cache 目录才是你真正的“热备”核心
Composer 默认把下载的 .zip 和 .tar 包存在 ~/.composer/cache/files/ 下，按 vendor/name 哈希分层存储。只要不手动清空（composer clear-cache）或删掉该目录，重复 install 会直接复用本地文件，毫秒级完成。
立即学习“PHP免费学习笔记（深入）”；
- 确认缓存位置：
composer config cache-dir - 查看缓存大小：
du -sh $(composer config cache-dir)（常见项目积压后可达 2–5GB） - 迁移缓存到 SSD 或共享存储（如 NFS）可提升多项目构建速度，但注意
cache-dir必须对运行用户可读写 - 不要 symlink
cache-dir到系统临时目录（如/tmp），部分 CI 环境会定期清理
真要“全量备份”？用 packagist-api + curl 脚本，但别指望实时可用
Packagist 提供公开 API（https://packagist.org/packages/list.json 返回所有包名，再逐个 https://packagist.org/packages/{vendor}/{name}.json 拉元数据），但实际执行会遇到：
- API 限流严格（约 10 请求/秒，IP 级），全量拉取数百万包需数天，且中途失败难续传
- 包 ZIP 文件需从
dist.url下载，而该 URL 是 S3 或 GitHub Release 临时链接，48 小时后失效 - 无法还原
composer.lock中的 exact commit hash，因为镜像不保存 Git refs - 若硬要存，建议只定期导出
packages.json快照 + 最近 7 天高频包（按下载日志统计），并用nginx静态托管，作为断网时的只读 fallback
真正稳定的“热备”，是让每个开发机和构建节点都保持活跃缓存，并统一配置镜像源；所谓全量镜像，只是把运维复杂度从网络转移到磁盘和元数据同步上，而收益极低。
