Composer镜像非容灾方案，需配合签名验证、composer.lock固化及本地缓存协同生效；仅换源会跳过signature校验，导致安全风险。
Composer 镜像本身不是容灾方案，只是加速代理；真正的容灾能力来自镜像配置方式、本地缓存策略和 composer.lock 的使用逻辑——三者缺一不可。
为什么直接换镜像源反而增加风险
执行 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ 会完全替换官方源，导致 Composer 跳过 signature 校验。一旦镜像站缓存被污染（或未同步签名），composer install 就可能拉下篡改过的包。
- 镜像只代理元数据（如
packages.json），不生成或验证signature字段 - Composer 2.5+ 的安全机制依赖 packagist.org 响应体中的
signature字段，该字段国内镜像不提供 - 正确做法是保留官方源语义，仅将元数据请求走 HTTPS 镜像，包文件仍由官方 CDN 或带校验的分发链路提供
如何配置真正可用的镜像 fallback
Composer 不会自动在多个镜像间轮询失败请求，必须显式声明备用仓库顺序，并配合签名验证启用。
- 全局启用签名验证：
composer config -g security.signature true - 设置可信 HTTPS 镜像（仅代理元数据）：
composer config -g repos.packagist.type composer，再执行composer config -g repos.packagist.url https://mirrors.aliyun.com/composer/ - 确认 HTTPS 强制开启：
composer config -g secure-http true（默认已开，禁用它会导致 HTTP 镜像被接受） - 验证生效：
composer diagnose输出中需同时出现secure-http: OK和signature verification: OK
本地缓存和 composer.lock 才是宕机时的保命线
只要 composer.lock 存在且完整，composer install 就可以完全离线运行——它只读取 ~/.composer/cache/files 中已下载的 zip 包并校验哈希，不发起任何网络请求。
- 确保
composer.lock提交进 Git，禁止出现在.gitignore中 - CI 环境务必挂载
~/.composer/cache目录（如 GitHub Actions 使用actions/cache缓存该路径） -
composer update必须联网，无法绕过；宕机期间应避免执行，除非已切到可用镜像并延长超时：composer config -g process-timeout 1800 - 临时极端情况可强制离线：
composer install --no-plugins --no-scripts，但前提是缓存中已有全部包的 dist 文件
最容易被忽略的是：镜像配置 ≠ 容灾配置。很多人配了阿里云镜像就以为高枕无忧，却没开 signature 验证、没固化 composer.lock、也没在 CI 中复用缓存——结果镜像一延迟，构建照样失败。容灾不是加一个 URL，而是一整套协同生效的约束组合。
