根本原因是网络层连通性失败，而非认证或权限问题；需用curl或git手动测试仓库URL连通性，检查代理、Docker网络、HTTPS证书及仓库索引是否真实存在。
Composer install/update 报错 “Could not fetch packages” 或 “Failed to download”
根本原因通常不是 Composer 本身坏了，而是它连不上你配置的某个仓库（尤其是私有仓库或自定义 repositories）。报错里提到“无法获取存储库信息”，重点不在认证或权限，而在于网络层连通性——curl 或 git 命令都打不通那个 URL，Composer 自然没法继续。
验证方式很简单：别依赖 Composer 报错信息，直接手动模拟它的底层行为。
- 如果是
type: "composer"仓库（比如私有 Packagist），用curl -I -v https://your-repo.com/packages.json看 HTTP 状态码和重定向链；404、502、超时都算失败 - 如果是
type: "vcs"（如 GitLab/GitHub 私有库），用git ls-remote --refs https://your-git.com/user/repo.git测试是否能列出远程 ref；提示fatal: unable to access就是网络或证书问题 - 注意 Composer 默认走系统 curl，不走 .gitconfig 的 proxy 设置；若公司有代理，需单独配
COMPOSER_HTTP_PROXY环境变量
packagist.org 能访问，但私有仓库 URL 显示“Connection refused”
这说明你的本地网络能出公网，但卡在私有仓库那层。常见于 Docker 容器内执行 composer install、CI runner（如 GitLab Runner）跑在隔离网络、或本地 hosts 文件误写。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- Docker 场景下，
host.docker.internal在 Linux 上默认不可用，要用--add-host=host.docker.internal:host-gateway启动容器才能解析 - 检查仓库 URL 是否用了
http://localhost:8080——对容器或远程 runner 来说，localhost 指的是它自己，不是宿主机 - 私有 Packagist 类服务（如 Satis、Private Packagist）若启用了 HTTPS 但证书是自签的，Composer 默认拒绝；临时解决可加
"secure-http": false到composer.json的config段（仅限内网环境）
使用 composer config repositories 添加了仓库，但 composer show 不显示包
添加仓库只是注册地址，并不触发同步。Composer 只在 install 或 update 时才真正请求该仓库的 packages.json 并缓存索引。
- 确认仓库 URL 后缀是
/packages.json（Composer 类型）或对应 Git 仓库地址（VCS 类型）；少个.json或多一层路径都会导致 404 - 运行
composer update --dry-run可看到 Composer 实际尝试访问哪些 URL，比盲猜更准 - 如果仓库返回 200 但内容为空 JSON（
{}），Composer 会静默跳过——检查该仓库是否真已 build 并 publish 过包，Satis 需要手动运行php bin/satis build
HTTPS 仓库被拦截，cURL error 60 或 “SSL certificate problem”
这不是 Composer 的 bug，是 OpenSSL 拒绝了不可信证书。尤其在 Windows 或某些 Linux 发行版上，CA 证书路径可能没对齐。
- 先用
php -r "print_r(openssl_get_cert_locations());"查看 PHP 认的 CA bundle 路径；再对比curl --version输出里的 ca-bundle 位置，两者不一致就容易出问题 - 临时绕过（仅调试）：设环境变量
export COMPOSER_DISABLE_TLS=1，但必须配合"secure-http": false，且绝不用于生产 - 长期解法：把企业根证书追加到 PHP 使用的
openssl.cafile指向的 PEM 文件末尾，然后重启 PHP-FPM 或 CLI 进程
最常被忽略的一点：Composer 的仓库探测是懒加载的。哪怕你 config 里写了十个仓库，只要没在 require 里用到对应包，它压根不会去连——所以“连接测试”必须基于你实际要装的那个包来触发，不能只看配置是否存在。
