composer配置失效的五大原因：①键名应为repo.packagist而非repos.packagist；②镜像url必须以/结尾，否则404；③项目级repositories字段会完全屏蔽全局配置；④必须执行composer clear-cache清除旧缓存；⑤最终验证需查看composer require -vvv日志中的实际请求域名。
repo.packagist写成repos.packagist就失效
很多人复制命令时多敲一个s，变成repos.packagist，结果composer config -g repos.packagist composer https://mirrors.aliyun.com/composer/执行无报错，但配置根本没写进生效字段。Composer 2.0+ 完全忽略这个键名，既不提示也不 fallback 报错，而是直接走默认源。
验证方式很简单：composer config -g repo.packagist必须返回完整 JSON 或至少含 URL 字符串；如果输出null、空值或报Key not found，说明你写的键名压根没被识别。
URL末尾缺/导致404而非超时
镜像地址不是“能连上就行”，必须以/结尾。比如https://mirrors.aliyun.com/composer少斜杠，Composer 会拼出/composerpackages.json这样的错误路径，返回 HTTP 404 —— 你看到的“下载失败”“找不到包”，大概率是这个原因，不是网慢也不是镜像挂了。
当前稳定可用的地址（2026年7月实测）：
https://mirrors.aliyun.com/composer/https://mirrors.cloud.tencent.com/composer/https://mirrors.huaweicloud.com/repository/php/
注意：任何http://开头的地址在 Composer 2.5+ 中会被直接拒绝连接。
项目级repositories字段会彻底屏蔽全局配置
只要项目根目录的composer.json里存在"repositories"字段（哪怕只是"repositories": []），全局的repo.packagist就完全失效。这不是优先级低，是硬性跳过，且不提示。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
检查方法：composer config repositories，如果输出里还含https://repo.packagist.org，说明你正被项目配置接管。
安全做法是进项目根目录后运行：composer config repo.packagist composer https://mirrors.aliyun.com/composer/（不加-g）。它会自动 merge 进composer.json的repositories对象中，key 固定为"packagist"。但前提是repositories得是对象{}，不是数组[]——后者会报错，需先手动改格式。
缓存不清，配置等于白设
旧缓存里存的是从packagist.org下载的packages.json快照，不清掉，Composer 就继续按旧元数据解析依赖。结果就是composer update找不到新包、锁文件校验失败、甚至报Package not found。
必须执行：composer clear-cache。验证是否清干净：
- Linux/macOS：检查
~/.composer/cache/是否为空 - Windows：检查
%APPDATA%\Composer\Cache\
更保险的做法：composer config -g cache-dir /tmp/composer-cache-empty && composer clear-cache，强制换路径再清。
真正生效的关键不在命令有没有执行成功，而在composer require xxx -vvv日志里出现的是aliyun.com还是packagist.org——其他所有判断都是间接的，只有真实请求域名不可绕过。
