composer config -g repo.packagist 失效主因是键名错（应为单数repo）、缺type值“composer”、url末尾无/，三者任一出错即静默回退官方源；验证须输出完整json对象如{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。
composer config -g repo.packagist 命令为什么没生效
大概率是三个硬性条件漏掉一个：键名写成 repos.packagist（多了一个 s）、漏掉 composer 这个 type 值、URL 末尾没加 /。这三处任一出错，Composer 2.x 都会静默 fallback 到官方源，不报错也不提示。
验证是否写入成功，直接运行：composer config -g repo.packagist。输出必须是类似 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"} 的完整 JSON 对象。空、null、报错或只返回 URL 字符串，都说明配置失败。
-
repo.packagist是固定键名，不能写成packagist.org或repositories.packagist -
composer是 type 值，不是可选参数，必须显式写出 - URL 必须是 HTTPS，且末尾带
/，例如https://mirrors.aliyun.com/composer/✅，https://mirrors.aliyun.com/composer❌
项目级配置比全局更可靠，尤其适合团队协作
全局配置看着省事，但实际容易踩坑：某些项目在 composer.json 里写了 "packagist.org": false，会直接屏蔽全局镜像；CI 流水线常以 www 或 runner 用户运行，而 -g 配的是当前登录用户的配置，权限不一致就失效；新人拉代码后行为不一致——全局配置无法被 Git 跟踪。
推荐做法：进项目根目录，运行 composer config repo.packagist composer https://mirrors.aliyun.com/composer/（去掉 -g）。它会自动在 composer.json 顶层写入 "repositories" 字段，key 固定为 "packagist"，不会覆盖已有私有源——前提是原来 repositories 是对象结构（不是数组）。
- 如果项目已存在
"repositories": []数组，命令会向末尾插入新项，不破坏原有私有源 - 千万别写
"packagist": false，这会导致基础包（如php、ext-json）校验失败 - 改完后运行
composer update --lock，确保composer.lock记录新源地址
换源后仍卡在 “Resolving dependencies”？和镜像无关
镜像只加速下载，不解决依赖解析慢的问题。如果你发现 composer update 卡在 Resolving dependencies 阶段几十秒甚至几分钟，基本可以确定是本地环境或 composer.json 写法导致的，和镜像源毫无关系。
- PHP 版本约束太宽，比如
"php": "^7.4 || ^8.0"，会让 Composer 尝试大量组合 - 大量未锁定版本的 dev 包（如
"monolog/monolog": "dev-main"） -
require-dev里塞了太多工具，尤其含已废弃的fxp/composer-asset-plugin - Xdebug 启用中：会让解析慢 5–10 倍，可用
php -d xdebug.mode=off $(which composer) install临时禁用
宝塔/CI 环境里全局配置为啥不起作用
全局配置写在 /root/.composer/config.json，但它只对 root 用户生效。宝塔「一键部署」、PHP 管理器、计划任务默认以 www 用户运行，根本读不到 root 的配置。
解决方法很直接：先确认实际执行用户（比如 whoami 或查日志 UID），再针对性配置。例如给 www 用户配：
sudo -u www composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/- 或在 CI workflow 中显式设置
COMPOSER_HOME=/home/www/.composer - GitHub Actions 等平台建议直接用项目级配置，避免权限歧义
