根本原因是composer self-update仅更新二进制，不修改仓库配置；新版本默认仍用官方源，且2.2+对键名敏感，必须用单数repo.packagist并带composer类型参数、url末尾加斜杠，再清缓存才生效。

Composer 版本切换慢，根本原因不是版本本身，而是每次 composer self-update 后首次运行（比如 composer install）仍会连 packagist.org——它不走镜像，也不受版本控制影响。真正要动的是「源配置」，不是版本。

为什么 composer self-update 后还是卡在 packagist.org？

因为 self-update 只更新 Composer 二进制，不碰任何仓库配置。新版本默认仍用官方源，且 Composer 2.2+ 对键名敏感，旧命令可能完全失效。

• repo.packagist 是唯一被广泛兼容的键名（单数、小写、无 s），写成 repos.packagist 或 repositories.packagist.org 都静默忽略
• 必须带 composer 作为第三个参数，表示 type 值：漏掉就 fallback 到 https://packagist.org
• URL 必须以 / 结尾，否则拼出 /composerpackages.json 导致 404
• 执行完必须跟 composer clear-cache，否则本地缓存的元数据仍指向旧源

composer config -g repo.packagist 总不生效的排查点

命令回显 success ≠ 真生效。常见失效不是网络问题，是配置没落进正确位置。

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

• 先查是否被项目级配置劫持：grep -A 5 "repositories" composer.json —— 如果存在，全局配置直接被跳过
• 确认写入位置：Windows 下 Git Bash 可能写进 %APPDATA%\Composer\config.json，而非 ~/.composer/config.json
• 验证真实生效值：composer config -g repo.packagist 输出必须是完整 JSON，如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}
• 看诊断输出：composer diagnose 中 “Repo” 行必须显示镜像域名，不是 packagist.org

不同场景下该用哪种镜像命令？

没有“通用最优”，只有“匹配上下文”。选错会导致协作冲突或 CI 失败。

• 个人开发机：用全局配置，命令一次，永久省心
  composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
• 团队项目（Git 可跟踪）：进项目根目录，去掉 -g，写入 composer.json
composer config repo.packagist composer https://mirrors.ustc.edu.cn/composer/
• CI 流水线或临时调试：不改任何配置，单次生效
  composer update -vvv --repository=https://mirrors.cloud.tencent.com/composer/
• 私有包混合场景：全局配镜像 + 项目里显式声明 "packagist": false，再单独加私有源，避免 fallback 错乱

最常被忽略的一点：镜像只代理元数据（packages.json），ZIP 包仍可能直连 GitHub。如果某个包下载慢，大概率是它没被镜像同步，而不是配置错了——这时候得看具体包的托管地址，不是换源能解决的。