diagnose 显示 OK 却卡在 Loading composer repositories，是因为 diagnose 仅对 https://packagist.org 发 HTTP HEAD 请求（端口 80），不走镜像、不校验证书、不触发 DNS/TLS，而真正卡住的是后续 GET packages.json 的完整网络流程。
为什么 diagnose 显示 OK 却卡在 Loading composer repositories
因为 composer diagnose 根本不走你配的镜像，也不走 HTTPS 或真实依赖链路。它只对 https://packagist.org 发一次 HTTP HEAD 请求（端口 80），不校验证书、不读 repos.packagist 配置、不触发 DNS 解析和 TLS 握手——所以“OK”毫无参考价值。
真正卡住的位置，是 Composer 启动后第一件事：向镜像源（或 fallback 的 packagist.org）GET packages.json，这一步需要完整 DNS + TCP + TLS + HTTP 流程。任何一环卡死，都会停在 “Loading composer repositories” 不动。
- 你执行了
composer config -g repos.packagist composer https://mirrors.aliyun.com/composer/，但diagnose仍连官方源 —— 这是设计如此，不是配置失败 - 卡住时
http.timeout参数完全无效，因为问题发生在网络栈底层（DNS 超时、SNI 被拦、证书信任链断裂），还没到 HTTP 客户端超时逻辑 - 用
curl -I https://mirrors.aliyun.com/composer/packages.json或composer show -p | head -5才能验证镜像是否真通
如何确认镜像配置是否真正生效
别信命令有没有敲对，要看 Composer 实际请求的域名。两个动作必须一起做：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 运行
composer config -g repo.packagist（注意是repo，不是repos）；输出必须是完整 URL 字符串，如https://mirrors.aliyun.com/composer/；若返回null、空值、https://packagist.org或报错，说明配置失败 - 再跑
composer install -vvv，滚动到最后几行，找类似Reading packages.json from cache at /https---mirrors-aliyun-com-composer/的日志；如果看到的是packagist.org/packages.json，说明 fallback 了，镜像没走通 - 常见静默失效点：
repos.packagist多写一个s、URL 末尾缺/（导致请求/composerpackages.json404）、漏掉中间的composer类型参数
SSL 错误（curl error 60 / 35）不是 Composer 配错了
这类错误本质是 PHP 的 OpenSSL 不认识证书颁发机构，和 Composer 的 cafile 配置无关——composer config --global cafile 只影响 Composer 自己的 HTTP 客户端，而 diagnose 和部分元数据加载走的是 PHP 原生 file_get_contents 或 cURL，用的是系统级 CA 信任链。
- 先查 PHP 实际加载的证书路径：
php -r "print_r(openssl_get_cert_locations());"，重点关注default_cert_file是否存在且可读 - 路径为空、文件损坏或过期？直接覆盖：
curl -o /etc/ssl/certs/ca-certificates.crt https://curl.se/ca/cacert.pem（路径按上一步输出调整） - 然后在真实生效的
php.ini里加一行：openssl.cafile=/etc/ssl/certs/ca-certificates.crt，并重启 PHP 进程（CLI 模式也要重启终端）
Resolving dependencies 卡住和镜像完全无关
这个阶段不发任何 HTTP 请求，纯本地计算：Composer 解析 composer.lock 或 composer.json，递归求解依赖约束，生成安装计划。卡在这里，说明你的依赖图太复杂、版本约束冲突严重，或 PHP 内存/性能不足。
- 不是网络问题，调
http.timeout、换镜像、清缓存全无效 - 加
-vvv看最后输出是否停在Resolving dependencies后无进展；如果是，尝试缩小范围：composer why-not vendor/package:version或临时删掉require-dev后重试 - 大项目建议加
--no-cache避免旧 lock 文件干扰，但更关键的是检查是否有循环依赖、过于宽松的版本约束（如"*"或"^1.0 || ^2.0"）
最易被忽略的一点：卡在 Loading composer repositories 是网络链路问题，卡在 Resolving dependencies 是算法+资源问题，二者成因、排查工具、解决路径完全不同，混在一起查只会浪费时间。
