composer config -g repo.packagist 命令失效的主因是键名、type值和URL格式三处必须严格正确：键名只能是repo.packagist，type值composer不可省略，URL须HTTPS且以/结尾；漏任一即静默失败。
composer config -g repo.packagist 命令为什么总不生效
不是镜像源不行，是命令写错了三个关键点就静默失败：键名必须是 repo.packagist（不是 repos.packagist、packagist 或 packagist.org），中间的 composer 是 type 值不能省，URL 必须用 HTTPS 且以 / 结尾——漏掉任意一个，composer config -g repo.packagist 查出来都是空或 null。
常见误操作包括：
- 在宝塔或 CI 中用 root 配了全局镜像，但实际执行的是
www或runner用户，读的是各自家目录下的~/.composer/config.json - 复制命令时漏掉
-g，结果只改了当前目录的composer.json，换个项目就失效 - 把
https://mirrors.aliyun.com/composer/写成http://或少斜杠，触发 404 或 fallback 到 packagist.org
项目级配置比全局更可靠，尤其在团队和 CI 场景
运行 composer config repo.packagist composer https://mirrors.aliyun.com/composer/（不带 -g）会自动向项目 composer.json 的 repositories 字段安全追加镜像条目，不覆盖已有私有源，也不破坏 JSON 格式。
这样做有几个硬性好处：
立即学习“PHP免费学习笔记（深入）”；
-
composer.json提交到 Git 后，所有协作者拉代码即用，行为一致 - GitHub Actions、GitLab CI 等容器环境无需额外配置，直接读取项目内定义
- 避免多个用户或项目共享同一全局配置导致的冲突（比如某项目必须走官方源做合规验证）
- 如果项目已有
"repositories": {}（空对象），命令能 merge；但若已是数组[]，会报错，需先手动改为对象
改完别忘了删掉 vendor/ 和 composer.lock，再跑 composer install ——旧 lock 文件里的 hash 可能和镜像元数据不匹配。
换镜像后还卡在 Resolving dependencies？那和镜像无关
镜像只加速包下载阶段（Downloading），不解决依赖解析（Resolving dependencies）慢的问题。这个阶段卡住，基本是本地环境或 composer.json 写法导致的。
真实瓶颈常见于：
- PHP 内存不足：
COMPOSER_MEMORY_LIMIT=-1临时放宽限制再试 - Xdebug 启用中：会让解析慢 5–10 倍，用
php -d xdebug.mode=off $(which composer) install临时禁用 -
"platform"配置与实际 PHP 版本不匹配：比如"php": "7.4"却在 PHP 8.2 上运行，触发降级查找逻辑 - require 太宽泛（如
"monolog/monolog": "^1.0 || ^2.0 || ^3.0"），让解析器穷举组合
临时验证镜像是否可用，别动任何配置
想快速测试某个镜像地址是否通、是否同步，又不想污染全局或项目配置，就用 --repository-url 参数：
composer install --repository-url=https://mirrors.aliyun.com/composer/
这个参数优先级最高，会覆盖全局和项目级设置，适合排查网络问题或 CI 脚本中动态指定源。但注意：
- 只对
install和update生效，require加这个参数不生效 - URL 必须完整、带 HTTPS 和结尾斜杠，否则卡在
Loading composer repositories几十秒后报Could not fetch .../packages.json - packagist.phpcomposer.com 已停用，现在只剩阿里云、腾讯云、中科大三家主流可用
真正容易被忽略的是：镜像配置只是第一步，后续所有依赖行为都建立在 composer.lock 和平台环境一致性上——哪怕 URL 全对，lock 文件没更新、Xdebug 没关、PHP 版本声明错，照样卡住不动。
