composer config -g repo.packagist 命令没生效最常见原因是键名必须为单数repo.packagist、type值必须显式写composer、url末尾必须带/，三者缺一即静默回退官方源；验证需输出完整json对象。
composer config -g repo.packagist 命令为什么没生效
最常见原因是三个硬性条件缺一不可：repo.packagist（注意是 repo 单数，不是 repos）、composer 类型值、URL 末尾必须带 /。漏掉任意一个，Composer 2.x 会静默回退到 https://packagist.org，不报错也不提示。
验证是否写入成功，直接运行：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，且结尾斜杠
/不可省略——少它会导致请求路径拼成/composerpackages.json，返回 404 - Windows 用户配置文件在
C:\Users\用户名\AppData\Roaming\Composer\config.json，别手写，用命令写入更安全
项目级配置如何避免覆盖私有仓库
项目已有 repositories 字段时，手动编辑 composer.json 极易出错：漏括号、引号不全、误删已有源。正确做法是让 Composer 自动合并：
- 进项目根目录，执行
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（不加-g） - 如果原
"repositories": {}是对象结构，命令会转为标准格式并追加"packagist"条目 - 如果原
"repositories": []是数组，命令会向末尾插入新项，不破坏原有私有源 - 千万别写
"packagist.org": false——这会导致基础包（如php、ext-json）校验失败 - 改完后运行
composer update --lock，确保composer.lock记录新源地址
宝塔/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 流水线（如 GitHub Actions、GitLab Runner）常以
runner或www-data用户运行，需对应用户执行配置命令 - 某些项目在
composer.json里写了"packagist.org": false，会直接屏蔽全局镜像——这种场景只能走项目级配置
换源后 still stuck at “Resolving dependencies”？
镜像只加速下载，不解决依赖解析慢的问题。如果你发现 composer update 卡在 Resolving dependencies 几十秒甚至几分钟，基本和镜像无关：
- PHP 版本约束太宽，比如
"php": "^7.4 || ^8.0"，会让 Composer 尝试大量组合 - 大量未锁定版本的 dev 包（如
"monolog/monolog": "dev-main"） -
require-dev里塞了太多工具（如phpstan、infection、pestphp），尤其含高阶约束的包 - 本地
composer.lock与composer.json不一致，触发全量重新解析
真正卡在这里，得看 composer diagnose 和 composer update -vvv 日志里实际请求的 URL 是否来自国内域名——这是排查“为什么还是慢”的第一手证据。
