报“Connection refused”或“cURL error 7”本质是系统级连通失败，需先验证DNS解析（如ping packagist.org）、确认全局镜像已设为https://mirrors.aliyun.com/composer/、清缓存（composer clear-cache），再排查代理、防火墙或容器网络权限问题。
Composer 安装过程报错，90% 不是 Composer 本身坏了，而是网络链路、PHP 环境或本地配置中某一个环节明确卡住了——先看错误关键词，再对症操作，比盲目重装快十倍。
报 “Connection refused” 或 “cURL error 7” 怎么办
这说明请求压根没发出去，或发出去后对方没响应。不是 Composer 版本低，也不是 PHP 扩展没开（php -m | grep curl 能看到就 OK），而是系统级连通失败。
- 先验证 DNS：运行
ping packagist.org，如果返回unknown host，说明 DNS 解析失败，该换 DNS（比如设为8.8.8.8）而不是调composer config - 确认是否用了镜像：运行
composer config -g repo.packagist，输出必须是https://mirrors.aliyun.com/composer/（注意是https，阿里云已停用 HTTP） - 换源后必须清缓存：
composer clear-cache，否则旧失败记录还在，重试照样走原地址 - 企业内网若走中间人代理，会静默触发连接拒绝；可临时验证：
composer config -g secure-http false+composer config -g cafile /dev/null（仅调试）
报 “Could not resolve host” 或 “connection timed out”
这类错误和 Composer 配置无关，它卡在系统 DNS 查询或 TCP 建连阶段。http.timeout 参数完全无效——它只管 HTTP 响应头返回时间，不参与解析域名或握手。
- 立刻改 DNS：Linux/macOS 编辑
/etc/resolv.conf加nameserver 8.8.8.8；Windows 在网络适配器里手动设置 - 验证是否被策略拦截：运行
curl -v https://mirrors.aliyun.com/composer/，看卡在* Connected to还是* TLS handshake - 若卡在 TLS，强制走 IPv4：
CURL_IPRESOLVE=4 composer install（Linux/macOS） - 别信
composer.json里的repositories——它优先级低于全局配置，且容易被 fallback 覆盖；必须用composer config -g repo.packagist全局设
报 “cURL error 60” 或 “certificate verify failed”
这不是网络问题，是 PHP 找不到或读不了可信 CA 证书。95% 的情况只需修对 php.ini 里的路径，而不是关 SSL 验证。
- 先查 PHP 认的证书路径：
php -r "print_r(openssl_get_cert_locations());"，重点关注default_cert_file和ini_cafile - 若路径为空、指向不存在的文件，或权限为 000，就必然失败；下载最新 CA 包：
curl -sS https://curl.se/ca/cacert.pem -o /usr/local/etc/openssl/cert.pem - 在 CLI 模式真正生效的
php.ini（运行php --ini看Loaded Configuration File）里加两行：openssl.cafile=/usr/local/etc/openssl/cert.pem和curl.cainfo=/usr/local/etc/openssl/cert.pem - 改完必须关掉当前终端，新开一个——CLI 下不重启服务，但要重载 PHP 配置上下文
报 “Your requirements could not be resolved”
这个错误说明 Composer 已经拿到所有元数据，但在本地求解依赖时找不到满足全部约束的版本组合。它不怪镜像、不怪网速，只怪约束之间打架了。
- 运行
composer why-not php:8.3（把8.3换成你目标版本），直接看到哪个包在拦路，比如输出laravel/framework v10.42.0 requires php ^8.1，但你项目里还有个包锁死了php: ^7.4 - 检查
composer.json里有没有写死版本号，例如"monolog/monolog": "2.9.0"，而新引入的包要求^3.0，两者无交集 - 确认 CLI 的 PHP 版本和扩展真实可用：
php -v和php -m | grep -E "mbstring|openssl|curl|json"，别只信phpinfo()页面——Web 和 CLI 可能加载不同php.ini - 临时绕过平台限制可用
composer install --ignore-platform-reqs，但它不会修复问题，只是掩盖；上线前必须让代码真兼容目标环境
最常被忽略的是 PHP CLI 和 Web 服务器加载的 php.ini 不一致——比如 php -m 显示有 openssl，但 php --ini 发现 CLI 加载的是另一个配置文件。这种差异比网络问题更隐蔽，也更容易导致安装中途静默失败。
