换国内镜像源不能解决所有慢的问题，但不换就一定慢；composer config -g repo.packagist命令需严格满足三要素：键名必须为单数repo.packagist、第二参数必须显式写composer、URL须以https://开头且末尾带/，缺一则静默回退官方源；验证输出应为{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}；卡在Resolving dependencies与镜像无关，属本地CPU依赖解析问题。
换国内镜像源不能解决所有慢的问题，但不换就一定慢——Composer 默认直连 packagist.org，在大陆环境下 TLS 握手常超 3s、首字节延迟高、甚至直接 503，这不是你网络差，是物理链路和防火墙共同导致的。
composer config -g repo.packagist 命令为什么总不生效
不是命令没运行，而是三个硬性条件漏掉任意一个，就会静默 fallback 回官方源，且完全不报错：
-
repo.packagist不能写成repos.packagist（多一个s就彻底失效） - 第二个参数必须是
composer（这是仓库类型声明，漏掉它 Composer 2.x 直接忽略配置） - URL 必须以
https://开头，且末尾带/：https://mirrors.aliyun.com/composer/✅，https://mirrors.aliyun.com/composer❌（少斜杠会导致路径拼成/p2//类错误，404）
验证是否成功：运行 composer config -g repo.packagist，输出应为完整 JSON，形如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。空、null、报错或仍显示 https://packagist.org，说明根本没写进去。
composer install 卡在 “Resolving dependencies”？镜像完全不管这事
这个阶段不走网络，纯 CPU 暴力求解依赖图——镜像再快也救不了。常见真实诱因：
立即学习“PHP免费学习笔记（深入）”；
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
"minimum-stability": "dev"强制拉取不稳定分支，候选版本数爆炸，求解时间翻 5–10 倍 -
"php": "^7.4 || ^8.0 || ^8.1"这类宽泛约束，让 Composer 查几百个包的兼容性元数据 -
composer.lock被删或未提交，install实际退化为update，触发全量解析 - 启用了
xdebug（php -v可确认），会让解析慢 5–10 倍——临时禁用：php -d xdebug.mode=off $(which composer) install
快速排查：进项目根目录，执行 composer config --list | grep repositories 看实际生效源；再跑 composer validate --strict 确认 lock 文件合法。
CI/宝塔/systemd 里镜像还是慢？用户权限搞错了
你在终端用 root 执行了 composer config -g，但宝塔后台、CI 脚本、systemd 服务往往以 www、git 或自定义用户运行，它们读的是各自家目录下的 ~/.composer/config.json。
- 查当前用户：在宝塔终端里运行
whoami或id -u - 给对应用户重配：
sudo -u www composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - Docker CI 中推荐改用项目级配置（写进
composer.json），比全局更可靠
临时验证是否真走镜像：加 -vvv 参数运行 composer install，日志里出现 mirrors.aliyun.com 或 mirrors.cloud.tencent.com 才算真正生效。
最易被忽略的点：换源后必须删掉 vendor/ 和 composer.lock 重装，否则旧 lock 文件里的哈希与镜像返回的元数据不匹配，会报 hash does not match 或直接失败——这不是镜像问题，是缓存残留。
