composer config -g repo.packagist 命令必须严格满足三要素：带-g参数、键名为repo.packagist（单数）、中间显式指定type值composer，且url须为https并以/结尾，缺一则静默失效，导致composer install仍直连packagist.org卡在元数据加载。
composer config -g repo.packagist 命令必须写对三要素，否则静默失效——不是网络慢，是根本没走镜像。
为什么 composer install 卡在 “Loading composer repositories”
这一步本质是拉取 packagist.org 的全量元数据（packages.json），不是下载 ZIP 包。国内直连时 DNS 解析慢、TLS 握手超时、CDN 节点远，导致卡住几十秒甚至报 403/503。镜像源必须同时提供元数据接口和包分发节点，二者 URL 结构要严格一致，否则会触发 Signature mismatch 或 Package not found。
composer config -g repo.packagist 必须满足的三个硬性条件
漏掉任意一个，命令不报错但完全不生效：
-
-g不能省：缺了就只改当前目录下的composer.json，换项目就失效 - 键名必须是
repo.packagist（单数、小写、无 s）：写成repos.packagist或packagist.org都会静默写入无效字段 - 中间的
composer是 type 值，不是注释或可选参数：正确写法是composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - URL 必须是 HTTPS + 末尾带斜杠：
https://mirrors.aliyun.com/composer/✅，https://mirrors.aliyun.com/composer❌（少斜杠会导致拼出/composerpackages.json报 404）
项目级配置比全局更可靠，尤其在 CI 和团队协作中
全局配置写在 ~/.composer/config.json，但宝塔以 www 用户运行、GitHub Actions 用 runner 用户、Docker 容器里常是 www-data —— 它们根本读不到你本地 root 的配置。
- 进项目根目录，运行
composer config repo.packagist composer https://mirrors.tuna.tsinghua.edu.cn/composer/（去掉-g） - 该命令会自动向
composer.json的repositories字段追加"packagist"条目，前提是原repositories是对象（如{}），不是数组（如[]） - 如果已是数组格式，命令会报错；此时应手动编辑，确保新增源排在首位，并保留原有私有源
- 改完必须删掉
vendor/和composer.lock，再执行composer install—— 旧 lock 文件里的哈希值绑定的是官方源，和镜像元数据不兼容
换源后仍卡在 “Resolving dependencies”？和镜像无关
镜像只加速元数据加载和 ZIP 下载，不参与依赖解析。如果你发现 composer update 卡在这一步几十秒以上，问题大概率出在：
-
"php": "^7.4 || ^8.0"这类宽泛约束，让 Composer 尝试大量版本组合 -
require-dev里塞了太多未锁定版本的工具链（如"phpunit/phpunit": "dev-main"） - 启用了
xdebug或 PHP 内存限制过低（memory_limit = 128M不够用） - 项目用了已废弃的
fxp/composer-asset-plugin，它绕过 Composer 镜像，直连 Bower/NPM 源
这些情况换任何镜像都无效，得收紧约束、拆分 require-dev、调高内存，或升级到现代替代方案（如 npm-asset-packagist.org）。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
