composer config repo.packagist 命令不生效是因为必须同时满足三个硬性条件：键名严格为单数 repo.packagist、第二个参数必须显式写 composer（type 值）、url 必须 https 且末尾带 /；任一缺失即静默回退 packagist.org，验证需输出完整 json 对象。
composer config repo.packagist 命令不生效？检查三个硬性条件
这条命令不是“配了就走”，漏掉任意一个条件，Composer 就静默回退到 packagist.org，连 warning 都不报。
必须同时满足：
-
repo.packagist是唯一合法键名（注意是 单数，repos.packagist或packagist.org全部无效） - 第二个参数
composer是type值，不是注释、别名或可选字段，必须显式写出 - URL 必须以
https://开头，且末尾带/：例如https://mirrors.aliyun.com/composer/✅，https://mirrors.aliyun.com/composer❌（少斜杠会导致请求/composerpackages.json404）
验证是否真写进去了？别信终端没报错——直接运行：composer config repo.packagist（不加 -g），输出必须是完整 JSON 对象，例如：{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。空、null、提示 Key not found，说明根本没写成功。
为什么 composer install 还在连 packagist.org？
配置写进去了 ≠ 立刻生效。Composer 的读取顺序是：项目级 repositories > 全局配置 > 默认源。但有两个关键陷阱：
- 如果
composer.json里原本没有repositories字段，或它是空数组[]（不是对象{}），composer config repo.packagist命令会失败或写入异常结构，导致整个repositories段被忽略 - 即使配置正确，
composer.lock里仍存着旧的dist.url（比如指向https://api.github.com/或https://packagist.org/），install会优先尝试 lock 文件里的地址，而不是镜像源
真正生效的标志是：composer.json 中出现标准结构："repositories": {"packagist": {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}}，且 "packagist.org": false 同级存在（否则镜像只是备选，不是唯一）。
如何安全清理并验证镜像是否真正生效
别只看命令有没有报错。换源后必须做三件事，缺一不可：
- 删掉整个
vendor/目录 - 删掉
composer.lock - 运行
composer install -vvv（不是update），并用2>&1 | grep -i 'mirrors\.aliyun'检查日志中是否出现镜像域名
额外验证步骤：composer diagnose 查看 Repo.packagist.org 行是否显示为你配的镜像 URL；composer clear-cache 清掉本地缓存，避免元数据残留干扰。
特定依赖不能走镜像？这不是 Composer 配置问题
composer config repo.packagist 只控制 Packagist 元数据源（即 packages.json 下载），它不决定具体包的 dist ZIP 或 TAR 包从哪下——那是每个包在 composer.lock 里记录的 dist.url 决定的。
如果你发现某个特定依赖（比如 monolog/monolog）仍然从 GitHub 下载 ZIP，而其他包走了镜像，原因通常是：
- 该包的
dist.url是硬编码的 GitHub 地址（如https://api.github.com/repos/monolog/monolog/zipball/...），镜像源无法代理这类直链 - 该包未发布到 Packagist 镜像（阿里云/腾讯云同步有延迟，新版本可能滞后 5–10 分钟）
- 你用了
--prefer-source或项目设置了"preferred-install": "source"，强制走 Git 克隆而非 dist 包
这种情况下，镜像配置本身没问题，但“特定依赖”不受其影响——这是设计使然，不是 bug，也无需特殊配置去绕过。
