根本原因不是镜像站挂了，而是命令写错后composer静默忽略——必须同时满足：单数键名repo.packagist、显式type值composer、https且末尾带/的url；任一缺失即失效，验证需输出完整json对象。
全局镜像配置 repo.packagist 为什么经常不生效
根本原因不是镜像站挂了，而是命令写错后 Composer 静默忽略——不报错、不提示、也不回退。必须同时满足三个条件：repo.packagist 键名（注意是单数 repo，不是 repos）、composer 类型值、HTTPS URL 且末尾带 /。
常见失效场景：
-
composer config -g repos.packagist composer https://mirrors.aliyun.com/composer/→ 多了个s，字段无效 -
composer config -g repo.packagist https://mirrors.aliyun.com/composer/→ 缺composertype，自动 fallback 到默认源 -
composer config -g repo.packagist composer http://mirrors.aliyun.com/composer/→ Composer 2.0+ 拒绝 HTTP，直接跳过
验证方式只有一条：composer config -g repo.packagist，输出必须是完整 JSON 对象，例如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}；空、null 或报 Key does not exist 都说明没写进去。
项目级 repositories 数组如何覆盖全局配置
只要项目 composer.json 里存在 "repositories" 字段（哪怕只是空数组 "repositories": []），全局配置就彻底失效——不是合并，不是追加，是整块丢弃。
这意味着：
-
composer create-project laravel/laravel默认走模板里的repositories，无视你配的全局镜像 - CI 环境或 Docker 容器中，若没同步
~/.composer/config.json，全局配置根本不存在 - 团队协作时，项目级配置提交 Git 后行为一致，比全局更可靠
临时绕过项目配置：加 --repository-url=https://mirrors.aliyun.com/composer/ 参数；长期方案是删掉 composer.json 中的 "repositories" 块，再跑 composer install。
repositories 数组顺序决定实际查找路径，不是“谁先写谁赢”
Composer 不是挨个请求、等超时再试下一个，而是对每个仓库并发检查元数据是否声明支持目标包（比如通过 packages 字段或 provider-includes）。首个返回有效 JSON 的仓库即生效，后续全跳过。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
典型错误配置：
- 私有 Satis 源没生成
provider-includes，导致每次拉全量packages.json，体积大、解析慢，你以为是“顺序没生效” - 把
https://packagist.org/和镜像 URL 混写进同一个repositories数组 → 前者会抢在镜像前触发真实网络请求，一断网就卡死 - 写了两个私有源都声明支持
monolog/monolog，Composer 只取第一个返回有效 JSON 的，后一个完全忽略
正确做法：私有源置顶，镜像源用 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"} 显式声明，并确保排在其后；如需禁用兜底行为，末尾加 {"packagist.org": false}，且必须是独立对象、不能嵌套。
为什么 composer install 还在请求 packagist.org
日志里出现 https://packagist.org/packages.json 或 https://repo.packagist.org，基本等于镜像没生效——不是网络慢，是根本没读到你的配置。
真正起效的标志只有一条：Reading packages.json from cache at /home/user/.composer/cache/repo/https---mirrors-aliyun-com-composer/packages.json。
排查步骤：
- 运行
composer clear-cache（不是cache-clear，后者已废弃） - 加
--no-cache参数执行composer install -vvv，观察日志中请求域名是否变成镜像地址 - 确认
composer.lock里记录的 dist URL 是否仍指向packagist.org—— 如果是，删掉vendor和composer.lock再重装
最容易被忽略的一点：镜像只加速下载，不改变依赖解析逻辑；如果 composer.json 里约束太宽（如 "^2.0"），composer update 卡住是本地计算问题，换镜像也救不了。
