执行 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ 可解决90%的 require 卡顿，因默认直连 packagist.org；常见失效原因包括拼写错误、URL 缺尾斜杠、项目级 repositories 覆盖全局配置等。
直接执行 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ 就能解决 90% 的 composer require 卡顿问题——不是网络差，是默认还在直连 packagist.org。
为什么 composer require 还在访问 packagist.org
执行 composer require monolog/monolog 卡住、超时或报 cURL error 28，大概率不是你服务器没联网，而是 Composer 根本没走你设的镜像。常见原因有：
-
composer config -g repos.packagist（多写了一个s）——Composer 静默忽略，不报错也不生效 - 用了旧版命令
composer config -g packagist（缺repo.前缀），1.x 兼容但 2.2+ 不认 - URL 末尾漏了
/，比如写成https://mirrors.aliyun.com/composer，部分版本会拼出https://mirrors.aliyun.com/composer/packages.json以外的错误路径 - 项目根目录存在
composer.json且含"repositories"字段，它会完全屏蔽全局配置
验证 composer require 是否真走镜像
光看 composer config -g repo.packagist 输出还不够，得看到实际请求发到了镜像域名才算数。最可靠的方式是加 -vvv 并过滤日志：
运行：composer require monolog/monolog --no-install -vvv 2>&1 | grep "Downloading"
输出里必须出现类似 mirrors.aliyun.com 或 mirrors.cloud.tencent.com 的路径。如果还看到 packagist.org，说明 fallback 了，配置没覆盖成功。
注意：--no-install 能跳过实际下载，只做元数据解析和 URL 构建，更快验证；2>&1 把错误流也转为标准输出，确保 grep 能捕获到。
composer require 换源后仍卡在 Resolving dependencies
这个阶段不走网络，换镜像完全无效。卡在这里说明依赖解析本身出了问题，和镜像源无关。典型诱因包括：
-
composer.json里"php"版本约束太宽，比如"^7.4 || ^8.0 || ^8.1"，Composer 要遍历所有兼容组合 - 大量未锁定版本的
dev-包或require-dev工具链（如phpunit/phpunit用"^10"而非"10.5.0"） - 本地
composer.lock和composer.json冲突，或 PHP 扩展缺失（如mbstring、xml未启用）导致某些包无法加载元数据
此时应运行 composer diagnose 查看环境报告，再用 composer show --platform 确认已启用扩展。
项目级配置比全局更可控，尤其对 composer require
团队协作或 CI 场景下，全局镜像容易被覆盖或引发 hash 不一致。推荐进项目根目录后执行：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/
这条命令会在 composer.json 顶层自动添加 "repositories" 字段，key 必须是 "packagist"，不能是 "aliyun" 或其他别名。效果是：composer require、install、update 全部走该镜像，且提交后所有协作者行为一致。
若项目已有 "repositories"，别手动编辑 JSON——用命令追加，否则可能误删私有包源；改完立刻 composer clear-cache，否则旧缓存可能干扰首次 require。
