Packagist.org 宕机时 composer 命令会卡在 packages.json 请求上，可配置国内镜像（如阿里云、腾讯云）绕过；全局用 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，项目级用 composer config repo.packagist composer https://mirrors.cloud.tencent.com/composer/，验证用 composer config repo.packagist。
Packagist.org 宕机时，composer install 和 composer update 会卡在 https://packagist.org/packages.json 请求上，超时失败——这不是你项目的问题，但确实会阻断本地开发、CI 构建甚至线上部署。
如何快速切换到国内镜像（如阿里云、腾讯云）
Composer 支持全局或项目级配置镜像源，优先走国内 HTTPS 镜像可绕过 Packagist.org 直连。注意：必须用 composer config 设置，手动改 composer.json 的 repositories 不生效（除非显式禁用 packagist.org）。
- 全局设置（推荐 CI/多项目场景）：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
- 项目内设置（不影响其他项目）：
composer config repo.packagist composer https://mirrors.cloud.tencent.com/composer/
- 验证是否生效：
composer config repo.packagist应输出镜像 URL；运行composer show --platform不报 502/timeout 即说明通路正常 - 镜像不是实时同步的，阿里云和腾讯云通常延迟
为什么 composer.lock 是你的“保命文件”
只要项目已有 composer.lock，且所有依赖包已存在于本地缓存（~/.composer/cache），composer install 就完全不依赖远程源——它只校验哈希、解压本地 zip 包。这是你应对突发宕机最轻量的自救方式。
- 确保团队提交
composer.lock到 Git（禁止 .gitignore 排除） - CI 流水线应复用缓存目录（如 GitHub Actions 的
actions/cache缓存~/.composer/cache） - 本地执行过
composer install后，缓存目录里会有大量.zip和.json文件；下次宕机时直接rm -rf vendor && composer install仍能成功 - 注意：
composer update必须联网获取最新元数据，无法绕过；此时只能切镜像或等待恢复
临时禁用 Packagist.org 并启用离线模式
当镜像也异常（极小概率），或你明确知道只需重装已有依赖时，可强制 Composer 进入“离线优先”逻辑。关键不是关掉网络，而是让 Composer 主动跳过所有远程请求。
- 临时禁用官方源：
composer config --unset repos.packagist
（注意不是repo.packagist，大小写敏感） - 启用离线模式：
composer install --no-interaction --prefer-dist --offline
-
--offline会让 Composer 拒绝任何 HTTP 请求，仅从vendor/和缓存中还原；若缓存缺失某包，会直接报错而非降级尝试 - 此模式下
composer require无效，因为无法解析新包信息；仅适用于已锁定依赖的部署或重装场景
真正容易被忽略的是缓存路径权限和镜像同步滞后性：CI 容器里如果每次清空 ~/.composer/cache，又没预热，那切镜像也没用；而某些企业防火墙会拦截非官方域名的 HTTPS SNI 请求，导致镜像返回空响应——这时得检查 curl -I https://mirrors.aliyun.com/composer/packages.json 是否真能通。
