composer install卡在“loading composer repositories”是因packagist.org在国内不可用，必须配镜像；config -g repo.packagist失效主因是键名错（如repos.packagist）、缺type值composer、url末尾无/，三者缺一即静默回退官方源。
Composer install卡在“Loading composer repositories”不是你网络差，是默认源https://packagist.org在国内根本连不上——DNS慢、TLS握手不稳定、CDN缺失，三者叠加导致元数据拉取超时或无限挂起。必须配镜像，不是“可选优化”，而是能跑起来的前提。
composer config -g repo.packagist 命令为什么总不生效
90% 的失败不是网络问题，是命令写错三个硬性条件，且 Composer 会静默忽略，不报错也不提示：
-
repo.packagist是固定键名，不能多写一个s（比如repos.packagist）或漏掉repo.前缀 -
composer是 type 值，必须显式写出，不能省略；省了就 fallback 回官方源 - URL 必须用 HTTPS，且末尾必须带斜杠
/，少斜杠会导致拼出/composerpackages.json404
验证是否写入成功，只看这一条命令输出：composer config -g repo.packagist。返回空、null 或报 Key not found，说明没生效，立刻重敲。
项目级配置比全局更可靠，尤其在 CI 和宝塔环境
全局配置写在 ~/.composer/config.json，但宝塔以 www 用户运行、GitHub Actions 用 runner 用户、Docker 容器里可能是 app 用户——它们根本读不到你本地 root 或 $USER 的配置。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
进项目根目录，执行：composer config repo.packagist composer https://mirrors.aliyun.com/composer/（去掉 -g）
- 它会自动往
composer.json顶层写入"repositories"字段，key 固定为"packagist" - 如果已有
"repositories": {}（对象），命令安全 merge；如果是"repositories": []（数组），会报错，需先手动改成对象 - 改完必须删掉
vendor/和composer.lock，再跑composer install，否则旧 lock 文件里的 hash 可能和镜像元数据不匹配
换源后 still stuck at “Resolving dependencies”？和镜像无关
镜像只加速元数据拉取和 ZIP 包下载，不解决依赖解析本身慢的问题。如果你发现 composer update 卡在 Resolving dependencies 几十秒甚至几分钟，基本可以确定是以下原因：
-
"php": "^7.4 || ^8.0"这类宽泛版本约束，让 Composer 尝试大量组合 - 用了太多
dev-main或未锁定的分支版本 -
require-dev里塞了十几个调试工具，又没加--no-dev
这类问题不会因换镜像改善，得从 composer.json 约束写法和 PHP 版本策略入手。
最易被忽略的一点：镜像地址和元数据签名必须严格匹配。用清华源就得用 https://mirrors.tuna.tsinghua.edu.cn/composer/，换成阿里云地址却保留旧 lock 文件，可能触发 Signature mismatch 错误——这不是网络问题，是校验机制在拦你。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
