可用，但Composer 1.x标准写法是packagist（无repo.前缀），2.x中repo.packagist虽部分支持但2.2+已不推荐；repos.packagist（带s）在所有版本均无效。
composer config -g repo.packagist 命令在旧版中是否可用
Composer 1.x 和 2.x 对配置键名的容忍度不同：repo.packagist 在 1.x 中是标准写法，但在 2.2+ 中已不推荐；而 repos.packagist（带 s）在所有版本里都无效，哪怕看起来执行成功，也完全不生效。
旧版（如 v1.10.22）必须用 packagist（无 repo. 前缀），新版（v2.2+）建议用 repositories.packagist.org 或严格保留 repo.packagist（单数、带 -g、type 值为 composer）。
- 查当前 Composer 版本：
composer --version - v1.x → 用
composer config -g packagist composer https://mirrors.aliyun.com/composer/ - v2.0–2.1 →
repo.packagist可用，但需确保 URL 末尾有/，否则请求路径拼错直接 404 - v2.2+ → 推荐
composer config -g repositories.packagist.org '{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}'，兼容性更稳
URL 末尾斜杠和 HTTPS 是硬性要求，不是可选项
无论 Composer 版本新旧，只要镜像地址缺了末尾 /，就会导致请求路径变成 /composerpackages.json 而非 /composer/packages.json，返回 404；HTTP 地址则被 v2.0+ 默认拦截，连握手都不通过。
- ✅ 正确：
https://mirrors.aliyun.com/composer/ - ❌ 错误：
https://mirrors.aliyun.com/composer（少斜杠） - ❌ 错误：
http://mirrors.aliyun.com/composer/（HTTP 不被接受） - 验证方式：
curl -I https://mirrors.aliyun.com/composer/packages.json应返回 200，且Content-Type: application/json
旧版 Composer 不校验签名，但镜像停用会导致静默失败
Composer 1.x 和早期 2.x（provider-*.json 的 Content-SHA256 或 .sig 签名，所以能跑通很多已下线的旧镜像（比如 packagist.phpcomposer.com），但这只是“暂时能用”，不是“还能用”。
-
packagist.phpcomposer.com已彻底下线，继续配置会报Could not resolve host或超时 - 中科大（
https://packagist.mirrors.ustc.edu.cn/）和腾讯云（https://mirrors.cloud.tencent.com/composer/）目前仍可用，但腾讯云需确认其服务端是否启用verify-signature（旧版无需，新版必须） - 阿里云镜像最稳妥：从 2025 年 Q3 起默认透传哈希，对新旧版本都兼容
- 执行
composer clear-cache后再试，避免旧缓存干扰判断
项目级配置比全局更可靠，尤其混用多版本时
全局配置在跨版本环境中极易冲突——比如你用 v2.9.6 配了 repositories.packagist.org，同事用 v1.10.22 拉代码后执行 composer install，可能因键名不识别而 fallback 到官方源，导致 composer.lock hash 不一致。
- 进项目根目录，运行：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（不加-g） - 它会在
composer.json中写入"repositories": {"packagist": {...}}，格式合法且 v1.x/v2.x 都认 - 若已有
"repositories"字段，命令会自动合并，不会覆盖私有源 - 提交
composer.json到 Git，所有人行为一致，CI 构建不再因环境差异失败
Loading composer repositories，等几十秒才报错。 
