必须显式配置repo.packagist并禁用fallback，否则Provider分片请求仍打向官方源；改repositories无效因Composer 3.x+硬编码packagist.org为权威元数据源，provider-*.json等索引文件不走repositories列表，仅全局设置repo.packagist才能接管全部元数据流。
必须显式配置 repo.packagist 并禁用 fallback，否则 Provider 分片请求仍会打向官方源；阿里云镜像虽同步快，但默认不接管 provider-*.json 请求，这是卡顿主因。
为什么改了 repositories 还是慢？
很多人在 composer.json 里加了自定义镜像：
"repositories": [
{
"type": "composer",
"url": "https://mirrors.aliyun.com/composer/"
}
]
但这只影响部分包安装逻辑，provider-*.json（如 provider-laravel~10.0.json）这类分片索引文件仍由 Composer 内部硬编码的 packagist.org 源发起请求——根本没走你配的 repositories 列表。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- Composer 3.x+ 把 Packagist 元数据视为“权威源”，独立于
repositories配置 -
composer config -g repos.packagist false是旧写法，已失效；正确关闭 fallback 的方式是设置repo.packagist - 执行
composer show packagist/support，若 URL 仍是https://repo.packagist.org/，说明镜像未真正接管元数据流
怎样让 Provider 请求全部走镜像？
全局配置是唯一可靠方式，命令必须带 composer 类型：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
- 不要手写
~/.composer/config.json，易格式错误或覆盖auth字段 - 项目级覆盖用
composer config repo.packagist composer https://mirrors.ustc.edu.cn/composer/，但要先确认项目composer.json里没重复声明packagist到repositories - 中科大镜像同步延迟更低，适合遇到
404 provider-xxx.json的场景；阿里云偶尔滞后 1–2 小时
Provider 索引卡住时怎么快速验证？
别等 composer install -v 跑完，直接看最后几行 URL：
- 如果停在
https://mirrors.aliyun.com/composer/p2/laravel/framework/10.0.0.json→ 镜像生效，问题在镜像本身同步延迟 - 如果停在
https://repo.packagist.org/p2/...或packages.json→ 镜像未接管，repo.packagist配置失败 - 临时验证：用
curl -I https://mirrors.aliyun.com/composer/p2/laravel/framework/10.0.0.json，返回200才算该包已同步
Provider 分片是按命名空间 + 版本范围生成的，不是所有包都实时存在；镜像站不会预生成全部分片，只同步被实际请求过的。这点和 packages.json 全量索引不同，容易误判为配置失败。
