必须通过-vvv日志抓包验证真实请求URL，运行composer clear-cache && composer require monolog/monolog -vvv | grep "Downloading"，确认出现mirrors.aliyun.com而非packagist.org；若失败则检查项目级repositories覆盖、镜像URL末尾斜杠、键名repo.packagist是否正确及执行用户配置权限。
怎么确认镜像正在被真实使用
别只看 composer config -g repo.packagist 的输出——那只是你“写了什么”，不是 Composer “用了什么”。真正生效的源，得从日志里抓包验证。
- 运行
composer clear-cache && composer require monolog/monolog -vvv - 在输出中搜索
Downloading，确认 URL 是https://mirrors.aliyun.com/composer/或类似镜像地址，而不是https://packagist.org/或https://repo.packagist.org/ - 如果看到后者，说明项目级
repositories字段覆盖了全局配置，或存在"packagist.org": false这类禁用项
为什么 composer install 还卡在 “Loading composer repositories”
这不是镜像没配好，而是请求压根没发出去——常见于项目级配置错误或镜像服务不可达。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 先检查镜像可用性：
curl -I https://mirrors.aliyun.com/composer/packages.json，返回200 OK才算正常 - 再查当前目录下
composer.json是否含"repositories"字段，尤其是"packagist.org": false或"packagist": false这种彻底关源写法 - 执行
composer config repo.packagist（不加-g）和composer config -g repo.packagist对比输出，确认哪一层在起作用
composer config -g 命令最容易踩的三个坑
这条命令看着简单，但错一个字符就静默失效，且不报错。
- 键名必须是
repo.packagist（单数repo），写成repos.packagist或packagist就存进无效字段 - 中间的
composer是 type 值，不是可选参数，漏掉它，Composer 2.x 会 fallback 到默认源 - URL 必须以
/结尾，https://mirrors.aliyun.com/composer/✅，少斜杠会拼成/composerpackages.json导致 404
宝塔、CI、Docker 环境里镜像不生效的根本原因
全局配置只对“执行命令的用户”有效，不是写一次就全局通用。
- 你在终端用
root执行了composer config -g，但宝塔后台是以www用户运行的，它读的是/home/www/.composer/config.json，根本看不到root的配置 - CI 脚本里用
sudo composer config -g，结果写进了root配置，而构建容器里实际用的是runner用户 - 解决办法很直接：确认实际执行用户（
ps aux | grep composer或查日志 UID），再用sudo -u www composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/重配
Resolving dependencies 卡住和镜像无关，那是 PHP 内存、Xdebug 或 platform 版本不匹配的问题。 
