composer install卡在loading package information，大概率因默认源packagist.org在国内访问不稳定，需换阿里云镜像源：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，并执行composer clear-cache生效。
Composer install 一直卡在 loading package information？
大概率是默认源 https://packagist.org 在国内访问不稳定，不是网络问题，而是 DNS 解析慢或连接超时。别急着换代理，先确认是否真被墙——用 curl -I https://packagist.org 测一下响应头，如果超时或返回 403，镜像就是刚需。
推荐直接用阿里云镜像（稳定、同步及时），执行这条命令即可全局生效：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
注意：repo.packagist 是 Composer 2.2+ 的写法；旧版本（packagist（不带 repo. 前缀），否则配置不生效。
项目级镜像配置 vs 全局配置，怎么选？
全局配置影响所有项目，省事但不够灵活；项目级配置更安全，尤其当你协作的项目要求必须走官方源做审计时。
项目级只需在项目根目录下运行（不用 -g）：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/
它会把配置写入当前项目的 composer.json 的 config 字段里，提交后团队成员自动继承。但要注意：
- 如果项目已有
repositories数组，别手动改 JSON，用命令行追加，避免格式错误 -
config下的镜像设置优先级高于全局，但会被repositories中同名仓库覆盖 - 某些 CI 环境（如 GitHub Actions）可能清空全局配置，靠项目级配置更可靠
换源后 composer update 报错 “Could not find package xxx”？
不是镜像坏了，而是你本地缓存了旧的元数据。Composer 不会自动刷新包索引，得手动清掉：
composer clear-cache
再执行 composer update。如果还报错，检查是否误配了私有仓库（比如写了 type: vcs 但 URL 错了），这类配置会中断整个包查找流程。
另外，有些包（尤其是 dev 分支或未发布 tag 的）在镜像中可能延迟同步（通常
composer config -g repo.packagist composer https://packagist.org
PHP 8.3 + Composer 2.7 下中文镜像兼容性要注意什么？
阿里云、腾讯云、华为云镜像都已支持 Composer 2.7，但有个细节：Composer 2.6 起默认启用 lock 文件的哈希校验，而部分老镜像未正确实现 packages.json 的签名字段，导致 composer install 失败。
遇到 Invalid signature in packages.json 错误时，别降级 Composer，试试加参数跳过校验（仅限开发环境）：
composer install --ignore-platform-reqs --no-plugins
更稳妥的做法是换用明确标注支持 Composer 2.6+ 的镜像源，比如：
composer config -g repo.packagist composer https://packagist.phpcomposer.com
这个源由社区维护，对新版校验逻辑适配更及时。不过它的同步稳定性略逊于阿里云，日常开发用阿里云，CI 构建失败时再临时切过去排查。
镜像不是一劳永逸的开关，关键在理解它和 Composer 加载链的关系：请求先走 repositories 列表，匹配不到才 fallback 到 packagist；缓存、锁文件、PHP 版本约束都会交叉影响结果。调不通时，先 clear-cache，再看 composer diagnose 输出，比反复换源更省时间。
