正确输出应为{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}，需严格满足键名repo.packagist、type值composer、HTTPS且末尾带/三要素，缺一即静默回退官方源。
composer config -g repo.packagist 输出是什么？
这是你求助时必须贴出的第一行信息。它直接告诉你镜像有没有配进去——不是“我执行了命令”，而是命令执行后实际存了什么。
常见无效输出：
-
https://packagist.org→ 没切源，还在直连官方 -
null或空行 → 配置根本没写成功（键名错、缺-g、权限不足） -
https://packagist.phpcomposer.com→ 用了已下线源，得立刻换
正确输出应类似：{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}（注意末尾斜杠和完整 JSON 结构）
composer install -vvv 日志前 15 行里 Downloading 域名是哪个？
别信 “Loading repository” 这种模糊描述，真正走的是哪条路，只看 Downloading https://... 开头那一行。
关键判断点：
- 出现
packagist.org或repo.packagist.org→ 全局配置失效，或被项目级"repositories"字段覆盖 - 出现
mirrors.aliyun.com但后面跟/p2/xxx.json→ URL 少了末尾/，路径拼错导致 404 - 卡在
Resolving dependencies超过 30 秒 → 和镜像无关，是 PHP 版本约束太宽或 dev 分支依赖太多
你是不是在公司网络、CI/CD 或 Docker 里跑的命令？
这类环境最容易踩坑，但很多人提问时完全不提，导致别人反复猜。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
必须说明的细节：
- 是否设置了
HTTP_PROXY或HTTPS_PROXY环境变量？ - 运行命令的用户是谁？
ls -ld $(composer config -g home)看缓存目录归属是否匹配 - Docker 构建中用的是
root还是www-data？全局配置写在/root/.composer，但www-data根本读不到 - 是否在 WSL 下，项目路径是
/mnt/c/xxx？NTFS 权限会导致vendor/创建失败，和镜像无关
curl -I 测的镜像地址返回什么状态码？
composer diagnose 不验证镜像连通性，它只连官方源。真正有效的测试是手动测你配的地址：
运行：curl -I https://mirrors.aliyun.com/composer/packages.json
期望结果必须是：HTTP/2 200 或 HTTP/1.1 200 OK
其他情况代表真实问题：
-
301 Moved Permanently→ 镜像站强制 HTTPS，你用了 http 协议 -
404 Not Found→ URL 少了末尾/，或用了已停用地址（如phpcomposer.com） - 超时或 TLS handshake timeout → DNS 解析失败、代理干扰、或企业中间人证书未信任
最后提醒一句：别只贴报错文字。Composer 报错里最没用的就是 file_put_contents(): Only variables should be passed by reference 这类看似 PHP 语法错误的提示——八成是镜像返回了 HTML 页面或乱码 JSON，解析阶段就崩了。真正线索永远藏在 -vvv 日志第一行和 curl -I 的响应头里。
