验证镜像是否生效必须三者同时满足：composer config -g repo.packagist输出完整JSON如{"type":"composer","url":"https://mirrors.aliyun.com/composer/"}；composer diagnose显示阿里云地址；composer install -vvv日志含mirrors.aliyun.com。
命令没报错 ≠ 镜像真在用。验证必须看三处输出，缺一不可，否则你还在连 packagist.org。
composer config -g repo.packagist 输出必须是完整 JSON
这条命令不是“查有没有配置”，而是“查 Composer 当前读到的有效配置”。很多人的输出是 null、空行，或直接返回 https://packagist.org，说明根本没写成功。
- 正确输出示例：
{"type":"composer","url":"https://mirrors.aliyun.com/composer/"}（注意末尾有/，且含"type":"composer"） - 常见失效原因：
repos.packagist（多 s）、repository.packagist（少 o）、漏掉中间的composer（即 type 值） - Windows 用户特别注意：如果之前用过管理员权限运行过
composer config -g，实际写入的是%APPDATA%\Composer\config.json，但当前终端可能读的是另一个路径——先运行composer global config --list --verbose确认Loaded config file:路径
composer diagnose 必须显示阿里云地址
composer diagnose 的 “Repo:” 行才是 Composer 运行时真正使用的源地址。它不看你 config 文件里写了啥，只看最终解析结果。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 若输出仍是
Repo: https://packagist.org，说明被覆盖了——大概率是项目根目录下composer.json里存在"repositories"字段（哪怕只是空对象{}或{"packagist.org": false}） - 检查方式：
grep -A5 '"repositories"' composer.json；若存在，临时重命名该字段或整个repositories键再试 - 别信 “我删了 repositories 就好了”——删完必须立刻执行
composer clear-cache，否则旧缓存仍会触发原始请求
composer install -vvv 日志必须含 mirrors.aliyun.com
这是最终确认。所有前面的检查都只是“配置看起来对”，只有网络请求日志能证明 Composer 真正发出了哪个域名的请求。
- 执行：
composer install -vvv 2>&1 | grep "Downloading" - 有效日志示例：
Downloading https://mirrors.aliyun.com/composer/p2/laravel/framework.json - 若看到
packagist.org或packages.json后接 404/timeout，说明 URL 少了末尾/（如https://mirrors.aliyun.com/composer→ 拼成/composerpackages.json，必 404） - Linux/macOS 用户注意：如果设置了
http_proxy或https_proxy环境变量，即使镜像配置正确，也可能被代理劫持——用echo $http_proxy检查，必要时unset http_proxy
最容易被忽略的是缓存和权限错位：改了配置但没清缓存，或者用 sudo 写进了 root 的 config.json，而日常开发用的是普通用户。验证链路上任何一环断开，就等于没换源。
