“connection reset by peer”是中间设备主动中断tcp连接，非composer故障；需先运行composer diagnose和curl -i https://packagist.org确认系统级网络/dns异常，再针对性调整ipv4、ssl验证、镜像源、超时或代理配置。
“Connection reset by peer”不是 Composer 崩了，是它在建立 HTTPS 连接时被中间设备（防火墙、代理、NAT 网关、甚至旧版 OpenSSL）主动掐断。直接改 composer.json 或重装 Composer 没用，得从网络链路一层层往下压。
先确认是不是 Composer 的问题
别一上来就调配置——先看系统级连通性是否正常：
- 运行
composer diagnose，重点盯 HTTPS connectivity 和 GitHub API connectivity 两行，标 ERROR 才值得继续 - 手动测：执行
curl -I https://packagist.org和ping github.com，如果这两个也失败，问题出在系统网络或 DNS，不是 Composer - 再试
git clone https://github.com/composer/composer.git，若报fatal: unable to access 'https://': Failed to connect to github.com port 443: Connection reset by peer，基本锁定是企业策略拦截或 TLS 握手失败
排查 SSL/TLS 握手失败（cURL error 35 最常见）
这是“连接重置”里最隐蔽的一类：网络通、DNS 解得开，但 TLS 协商卡在第一步。典型表现是 composer install -vvv 输出停在某个 HTTPS URL 后无响应，或直接报 cURL error 35：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 检查 OpenSSL 版本：
openssl version；低于OpenSSL 1.1.1（如 CentOS 7 自带的 1.0.2k）无法协商 TLS 1.3，而 Packagist 已逐步强制要求 - 验证 CA 证书路径是否生效：
composer config -g cafile应返回你指定的 PEM 文件路径；若为空，说明没配对，或证书格式不对（必须是 PEM，不能是 DER） - 临时绕过验证仅用于诊断：
COMPOSER_NO_SSL=1 composer install，若此时成功，100% 是证书链或协议问题——但执行完立刻删掉该环境变量，否则后续全走明文 - Windows 用户还要检查
php.ini中curl.cainfo是否指向有效证书文件（如curl-ca-bundle.crt）
换镜像源 + 清缓存 + 调超时（国内环境必做）
直连 packagist.org 在国内极易触发连接重置，尤其高峰时段。这不是“不稳定”，而是连接被主动拒绝：
- 切阿里云镜像：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 清缓存（不是
cache-clear）：composer clear-cache；缓存损坏会导致后续所有请求都复用错误快照 - 延长超时：
composer config -g process-timeout 1800和composer config -g http-timeout 600；process-timeout控制整个命令生命周期，比--timeout更关键 - 若公司有代理，必须显式配置：
composer config -g http-proxy http://proxy.example.com:8080；不用时及时清除：composer config -g --unset http-proxy
强制 IPv4 + 验证配置优先级（容易被忽略的坑）
IPv6 路由异常或 DNS 返回 AAAA 记录但本地不支持，常导致 TLS 握手阶段被重置；另外，很多人设了全局镜像，却忘了项目级配置和环境变量会覆盖它：
- 临时强制 IPv4：
CURL_IPRESOLVE=4 composer install（Linux/macOS）；Windows 可先set CURL_IPRESOLVE=4再运行命令 - 检查当前生效的源：
composer config repo.packagist（不带-g），看是否被项目composer.json里的repositories块覆盖 - 确认没有冲突的环境变量：
echo $COMPOSER_REPO_PACKAGIST（Linux/macOS）或echo %COMPOSER_REPO_PACKAGIST%（Windows）；有值就清掉，否则它永远优先生效 -
composer install --no-cache比rm -rf vendor/ && composer install更安全，能跳过本地缓存干扰，避免重复拉取损坏包
最易被忽略的是：Composer 的“修复”本质是规避，不是纠错。它 fallback 到 source 是因为 dist 下载失败，但不会告诉你哪个包的 zip 校验失败；它降级 TLS 协议是为连上，但不会提示你证书已被代理重签。定位要靠 -vvv 输出里的 URL 和 composer diagnose 的 ERROR 行，而不是猜。
