换镜像源失败主因是三处细节错误：repo.packagist键名不能多s，type值必须显式写composer，URL须https开头且末尾带/；全局配置-g易在CI中失效，推荐项目级配置；卡顿多因依赖约束过宽或缓存未清。
直接结论：换镜像源本身不难，难在三处细节写错就静默失效——repo.packagist 键名不能多写 s，composer type 值必须显式写出，URL 必须是 https:// 开头且末尾带 /。90% 的“换源失败”其实根本没生效。
composer config -g repo.packagist 命令为什么总不生效
不是网络被墙，是命令格式硬性缺一不可：
-
repo.packagist是唯一合法键名（注意是单数repo，不是repos；也不能写成packagist.org） -
composer是 type 值，不是可选参数——漏掉就会 fallback 到官方源 - URL 必须以
https://开头，且末尾必须有/（少斜杠会拼出/composerpackages.json导致 404） -
-g不能省：缺了就只改当前项目，换目录或 CI 环境里就失效
验证是否成功：composer config -g repo.packagist 应输出完整 JSON，如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。空、null 或报错，说明没写对。
全局配置 vs 项目级配置，哪个更可靠
团队协作和 CI 场景下，项目级配置更可控：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 全局配置依赖当前用户权限，CI 流水线常以
www或runner用户运行，-g配的是登录用户，容易权限不一致 - 全局配置无法被 Git 跟踪，新人拉代码后行为不一致
- 项目级执行
composer config repo.packagist composer https://mirrors.cloud.tencent.com/composer/（去掉-g），会自动在composer.json顶层写入"repositories"字段，key 固定为"packagist"，不覆盖已有私有源 - 已有
"repositories"数组？别手动编辑 JSON，用命令追加，否则可能误删私有包源
注意：若项目已存在 "packagist.org": false，换源后仍需保留它，否则 Composer 可能 fallback 到官方源触发超时。
换源后仍卡在 “Resolving dependencies” 或 “Downloading”
这和镜像无关，是本地环境或配置问题：
- “Resolving dependencies” 卡住：基本是 PHP 版本约束太宽（如
"php": "^7.4 || ^8.0"）、require-dev里塞了太多未锁定版本的工具链——换任何镜像都无效 - “Downloading” 卡在
https://packagist.org/...：说明镜像根本没走通，先跑composer clear-cache，再删掉vendor/和composer.lock，最后composer install -vvv看日志里出现的是不是国内域名 - 镜像只加速
dist（ZIP/TAR），对source（Git clone）完全无效——检查composer.json是否含"prefer-source": true或硬编码了 Git 仓库地址 - CI 环境记得设
COMPOSER_IPV4=1，避免 IPv6 不稳定导致隐性延迟叠加
最易被忽略的一点：换源后首次安装，如果报 hash 校验失败或元数据不一致，不是镜像问题，而是旧缓存和旧 lock 文件在干扰——必须清缓存、删 vendor 和 composer.lock，从头来过。
