composer config -g repo.packagist总不生效是因为必须同时满足三点：键名严格为单数repo.packagist、中间参数必填type值“composer”、URL须HTTPS且末尾带/，任一错误即静默回退官方源，需通过该命令输出完整JSON验证并清缓存、删vendor与lock文件后重装。
配镜像源不是“可选项”，而是composer install能跑通的前提——没配对或没清缓存，90%的卡顿、超时、Could not find package都白折腾。
为什么composer config -g repo.packagist总不生效
这条命令本身没问题，但 Composer 2.x 对格式极其敏感，错一个字符就静默 fallback 到 https://packagist.org，且完全不报错。
-
repo.packagist必须是单数 —— 写成repos.packagist、repositories.packagist或packagist.org都无效 - 中间的
composer是type值，不是注释，不能省略；漏掉它，命令等价于没执行 - URL 必须是 HTTPS，且末尾带
/：https://mirrors.aliyun.com/composer/✅，https://mirrors.aliyun.com/composer❌（会拼出/composerpackages.json导致 404） - 验证是否真写入：运行
composer config -g repo.packagist，输出必须是完整 JSON，例如{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}；返回空、null、或仍是官方地址，说明失败
项目级配置比全局更可靠
CI 流水线（如 GitHub Actions）、宝塔、Docker 容器里运行的 Composer，往往用的是 www-data、runner 等非你本地用户的权限，根本读不到 ~/.composer/config.json。
- 进项目根目录，运行
composer config repo.packagist composer https://mirrors.tuna.tsinghua.edu.cn/composer/（不加-g） - 它会自动在
composer.json顶层写入"repositories"字段，key 固定为"packagist" - 前提是原
repositories是对象结构（如"repositories": {}），不是数组（"repositories": []），否则会报错 - 改完必须删掉
vendor/和composer.lock，再跑composer install——update不行，旧 lock 文件里的 hash 可能和镜像元数据不匹配
Drupal 项目必须用 repositories 数组，不能只设 repo.packagist
Drupal 常要同时拉私有模块（GitLab）、核心包（阿里云镜像）、通用组件（兜底官方源），单个 repo.packagist 根本不够用。
- 手动编辑
composer.json，在根节点同级加"packagist.org": false，并确保repositories是数组格式 - 私有 Git 源必须用
"type": "vcs"，URL 是可git clone的地址，不是网页链接 - 国内镜像建议放第二位（如阿里云），同步快、CDN 全；官方源放最后兜底
- 错误示例：
"repositories": {"packagist": false}—— 这只是个无效键值，"packagist.org": false才是真正关闭默认源的开关
换源后怎么确认真生效了
别信“命令没报错”，要看真实请求路径。三处交叉验证最准：
- 查配置：
composer config -g repo.packagist.url或composer config repositories.packagist.url，输出必须是你设的镜像域名 - 看诊断：
composer diagnose，找到Repo:那行，域名必须匹配（如mirrors.aliyun.com） - 抓日志：
composer install -vvv 2>&1 | grep -i "reading\|downloading"，出现的 URL 必须含镜像域名，且路径以/packages.json或/p2/结尾 - 如果三处都对，但依然慢或失败，优先检查 DNS 解析、CA 证书是否过期，或是否用了已废弃的
fxp/composer-asset-plugin（它不走镜像配置）
最容易被忽略的是：哪怕配置全对，只要本地缓存没清、composer.lock 没删、vendor 没清空，Composer 就可能继续用旧索引发请求——这不是镜像问题，是状态残留问题。
