90%的“connection refused”源于镜像未生效，需执行composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/（末尾带/）、composer clear-cache，并验证日志请求域名是否为mirrors.aliyun.com。
Composer报“Connection refused”或卡在downloading，本质是没切对镜像
这不是你本地网络断了，而是默认直连 packagist.org 被策略阻断。错误里带 Connection refused、failed to open stream 或长时间无响应，90% 是镜像没生效。
实操建议：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 运行
composer config -g repo.packagist，输出必须是https://mirrors.aliyun.com/composer/（注意结尾有/，且是 HTTPS）；若为空或仍是packagist.org，重跑一次composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 换源后必须清缓存：
composer clear-cache，否则旧 provider 路径仍会尝试走原地址 - 临时验证是否通：
composer install -vvv --no-progress，看日志里请求的域名是不是mirrors.aliyun.com - CI 环境（如 GitHub Actions）不会继承本地配置，必须在 workflow 里显式执行镜像设置命令
报 HTTP 404，先查镜像地址是否已失效或漏斜杠
404 Not Found 不代表包不存在，而是你正在请求一个根本不存在的 URL——常见于镜像地址写错、停服或末尾缺 /。
实操建议：
- 运行
composer config -g repo.packagist，如果含phpcomposer.com或laravel-china.org，立刻停用（这两个自 2022 年起固定返回 404） - 合法镜像 URL 必须以
/结尾，例如https://mirrors.aliyun.com/composer/；写成https://mirrors.aliyun.com/composer就会在拼p2/路径时 404 - 手动测通：
curl -I https://mirrors.aliyun.com/composer/packages.json，秒回HTTP/2 200才算活；返回 404 或超时，说明镜像不可用或被代理/DNS 拦截 - 必须删掉
vendor/和composer.lock后重装——composer.lock里硬编码了旧 provider 地址，不清除它，换源也白搭
报 cURL error 60 或 “certificate verify failed”，不是 Composer 问题，是 PHP 证书路径错
这类 SSL 验证失败，根源是 PHP 的 OpenSSL 扩展找不到可信 CA 证书，或系统时间偏差 >5 分钟。常见于 CentOS 虚拟机、Docker 容器或老旧 macOS。
实操建议：
- 先查证书路径：
php -r "print_r(openssl_get_cert_locations());"，重点关注default_cert_file值 - 若路径为空或指向不存在的文件（如
/etc/ssl/certs/ca-certificates.crt但该文件没生成），需手动下载并配置：curl -sS https://curl.se/ca/cacert.pem -o /usr/local/etc/openssl/cert.pem，再在php.ini中加一行openssl.cafile=/usr/local/etc/openssl/cert.pem - 检查系统时间：
date，若偏差超 5 分钟，SSL 握手必失败；CentOS 上执行sudo ntpdate -s time.nist.gov或启用chronyd - 不推荐长期关验证：
composer config -g secure-http false仅用于快速定位，生产环境禁用
报 “Your requirements could not be resolved”，这不是网络或镜像问题
这个错误说明 Composer 已连上镜像、也下载完全部元数据，但本地 SAT 求解器算不出满足所有约束的版本组合。跟网络、镜像、缓存都没关系。
实操建议：
- 运行
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 - 私有包未声明
"type": "vcs"会导致 fallback 到镜像找包，结果 404，现象和依赖冲突混淆，务必逐个注释repositories排查
composer.lock 的硬编码路径、以及私有包未声明 type 导致的 fallback 行为——三者出错，现象全是 404 或卡住，但根因完全不同。
