换国内镜像源不能解决所有慢的问题，但不换就一定慢；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 暴力求解依赖图——镜像再快也救不了。常见真实诱因：
-
"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 或直接失败——这不是镜像问题，是缓存残留。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
