Composer install卡在Resolving dependencies阶段主因是镜像未生效：repo.packagist键名须为单数、第二参数必填composer、URL须以/结尾，三者缺一即静默回退packagist.org；且需用对应用户重配、禁用packagist.org、清缓存并-vvv验证真实请求域名。
为什么composer install卡在Resolving dependencies阶段
根本不是网络慢，而是镜像元数据没真正生效——Composer 2.x 默认对 repo.packagist 的配置极其苛刻，错一个字符就静默 fallback 到 packagist.org，所有请求都变成跨洋 HTTP，Resolving dependencies 阶段会卡住几十秒甚至几分钟。
-
repo.packagist键名不能多写s（repos.packagist是 Composer 1.x 写法，2.x+ 完全忽略） - 第二参数必须显式写
composer，这是类型声明，漏掉等于没配 - URL 必须以
https://开头、结尾带/（https://mirrors.aliyun.com/composer/✅，https://mirrors.aliyun.com/composer❌） - 运行
composer config -g repo.packagist，输出必须是完整 JSON：{"type":"composer","url":"https://mirrors.aliyun.com/composer/"}
宝塔/CI里镜像配置不生效的真正原因
你在终端用 root 配了全局镜像，但宝塔走 www 用户，GitLab CI 走 runner 用户，systemd 服务走 www-data 用户——composer config -g 只写当前 shell 用户的 ~/.composer/config.json，其他用户完全看不到。
- 确认进程实际用户：宝塔看「网站」→「设置」→「运行目录」右侧的「运行用户」；CI 看
whoami输出 - 用对应用户重配：
sudo -u www composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - CI 脚本中别依赖全局配置，改用临时参数更稳：
COMPOSER_MEMORY_LIMIT=-1 php -d xdebug.mode=off $(which composer) install --no-dev --prefer-dist
项目级镜像配置为何仍走官方源
项目级配置不读全局 config，只认 composer.json 里的 repositories 对象，且必须显式禁用 packagist.org，否则它始终作为兜底源参与解析，部分包仍从国外拉。
-
repositories必须是对象（{}），不是数组（[]）；手写易出错，推荐用命令：composer config repo.packagist composer https://mirrors.aliyun.com/composer/ - 必须加
"packagist.org": false，完整结构示例："repositories": { "packagist": { "type": "composer", "url": "https://mirrors.aliyun.com/composer" }, "packagist.org": false } - 改完立刻删
vendor/和composer.lock，再跑composer install，否则 lock 文件仍锁定旧源地址
如何验证镜像是否真在用
别信 composer config 的输出，那只是你“写了什么”；要看 Composer 实际发出去的 HTTP 请求域名。
立即学习“PHP免费学习笔记（深入）”；
- 清缓存后开调试：
composer clear-cache && composer install -vvv 2>&1 | grep "GET https" - 正常应看到大量
GET https://mirrors.aliyun.com/composer/...；如果夹杂packagist.org或repo.packagist.org，说明配置未生效或packagist.org没禁用 - 注意
-vvv输出里Downloading行末尾的 URL，那是真实请求地址，不是拼接路径
packagist.org 不显式设为 false，哪怕镜像 URL 完全正确，它也会悄悄参与依赖解析，把整个流程拖进不确定性里。** 
