Composer镜像生效的唯一正确配置是composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，必须严格满足键名正确、type为composer、URL以/结尾，否则静默失效；验证需执行composer config -g repo.packagist并检查输出，且必须清缓存后重装。
国内 PHP 开发者不配 Composer 中文镜像，composer install 基本跑不完——不是慢，是卡在 Downloading、报 403、或直接 could not find package。这不是你网络差，是默认走 packagist.org 被限速+拦截的结果。
怎么确认镜像根本没生效
别猜，直接查配置输出：
- 运行
composer config -g repo.packagist，如果返回空、null、或仍是https://packagist.org，说明没写进去 - 新版 Composer（2.2+）可能只输出纯 URL 字符串，但只要不是
https://mirrors.aliyun.com/composer/这类地址，就等于没生效 - 加
-vvv跑一次composer install，看日志里下载域名是不是packagist.org——是的话，所有加速都白搭
全局配置命令必须严格满足三要素
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ 这条命令看似简单，漏掉任意一个细节都会静默失败：
- 键名必须是
repo.packagist（单数、全小写），写成repos.packagist或Repo.Packagist都无效 -
composer是type值，不是可选参数，不能省；漏了它，Composer 2.x 会 fallback 回官方源 - URL 必须以
https://开头，且末尾带斜杠：https://mirrors.aliyun.com/composer/✅，https://mirrors.aliyun.com/composer❌
项目级配置比全局更可靠，但别覆盖已有私有源
宝塔、CI、团队协作时，全局配置常因用户权限不同而失效（比如 root 配了，www 用户却读不到）。推荐进项目根目录执行：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
立即学习“PHP免费学习笔记（深入）”；
-
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（注意：不加-g） - 这条命令会自动往
composer.json的repositories字段里安全追加，前提是原字段为对象格式（如"repositories": {}） - 如果
repositories已是数组（"repositories": []），命令会报错，得先手动改成对象再运行 - 千万别在
repositories里写"packagist.org": false——这会关掉基础包校验，导致php、ext-json等平台依赖无法验证
换完镜像还卡在 Resolving dependencies？那和镜像无关
镜像只加速元数据请求和 tarball 下载，不参与依赖解析。如果你发现 composer update 卡几十秒，重点排查：
- PHP 内存不足（
COMPOSER_MEMORY_LIMIT=-1临时试一下） - xdebug 启用中（
php -d xdebug.mode=off $(which composer) install临时禁用） -
composer.json里"php"版本约束太宽（如"^7.4 || ^8.0"），或require-dev里塞了未锁定的工具链 -
composer.lock残留已下线包引用，删掉vendor/和composer.lock再composer install --no-cache
最易被忽略的点：镜像配置后必须清缓存，否则旧缓存仍指向 packagist.org —— 执行 composer clear-cache 再验证。另外，http-max-concurrent-downloads 可设为 10 提升并发下载效率，parallel-downloads 已弃用，设了也无效。
