上线时 Composer install 超时或失败主因是 packagist.org 国内访问不稳定，应改用阿里云官方镜像 https://mirrors.aliyun.com/composer/ 并在 CI 中临时配置源、使用 --prefer-dist 等参数确保稳定。
为什么上线时 Composer install 总是超时或失败
PHP 项目上线卡在 composer install，八成不是代码问题，而是默认源（packagist.org）在国内访问不稳定。DNS 污染、TLS 握手慢、连接重置频繁，导致依赖拉取失败或耗时飙升——尤其在 CI/CD 环境下，超时阈值低，更容易直接中断流水线。
解决思路很直接：把 packagist.org 替换成国内可用的镜像源，但必须注意两点：镜像是否实时同步、是否支持 HTTPS + 完整包完整性校验（Composer 2.2+ 默认启用 signaling 和 verify-signature）。
- 推荐使用
https://packagist.phpcomposer.com（阿里云维护，已停更）或更稳妥的https://mirrors.aliyun.com/composer/（阿里云官方镜像，持续更新） - 避免用已废弃的
https://packagist.phpcomposer.com，它不支持 Composer 2.5+ 的签名验证，会报错Invalid signature - CI 环境中不要依赖全局配置，应在项目级或构建命令中显式指定镜像，避免不同项目互相干扰
如何在 CI 流水线里安全切换镜像源
不能靠本地 composer config -g repo.packagist，CI 节点通常是干净容器，每次构建都得重置。最可靠的方式是在 composer install 命令前临时设置源，且不修改项目 composer.json。
示例（GitHub Actions）：
立即学习“PHP免费学习笔记（深入）”；
composer config repo.packagist composer https://mirrors.aliyun.com/composer/ && composer install --no-dev --optimize-autoloader --prefer-dist
关键点：
-
--prefer-dist强制走压缩包而非 Git 克隆，减少网络波动影响 -
--no-dev和--optimize-autoloader不仅提速，还降低因 dev 包镜像缺失导致的失败概率 - 不要用
composer config --global，某些 CI 环境（如 GitLab Runner）可能复用缓存，全局配置会污染后续任务
composer.lock 文件里藏着镜像兼容性隐患
如果项目已有 composer.lock，且之前用的是国外源生成的，直接切镜像可能触发哈希校验失败——因为部分镜像（尤其是非官方维护的）对 vendor 包的分发路径或压缩格式做了微调，导致 content-hash 不匹配。
上线前务必确认：
- 检查
composer.lock顶部的content-hash是否与当前镜像能解析的包一致；若不确定，CI 中加一步composer update --lock（不改依赖版本，只刷新 lock 文件中的 URL 和 hash） - 阿里云镜像支持标准 Packagist 协议，只要 Composer 版本 ≥ 2.2，无需额外配置就能正确解析
dist.url - 若出现
Package ... has no installation candidates，大概率是镜像未同步某个私有包或新发布版本，此时应 fallback 到原源（临时）或联系镜像维护方
自建镜像 or 用现成镜像？上线前必须权衡的点
团队规模大、有合规审计要求，才考虑自建镜像（如用 packagist-mirror 工具），否则纯属增加运维负担。现成镜像足够用，但要注意：
- 阿里云、腾讯云镜像都支持 HTTPS + 官方签名验证，可放心用于生产环境
- 别信“一键切换脚本”，很多脚本直接 sed 替换
composer.json，会误改 require 字段或破坏 JSON 格式 - 上线前在 staging 环境跑一次完整
composer install+ 启动测试，确认 autoloader 和 classmap 没异常——有些镜像返回的 zip 包结构略有差异，会导致class not found
镜像只是加速手段，真正容易被忽略的是 Composer 版本一致性：CI 用的 composer 可执行文件版本，必须和本地开发、线上运行环境完全一致，否则 lock 文件解析行为可能不同。
