答案是“unknown transport error”表示底层curl或php stream wrapper连接彻底失败，请求未发出或无响应，常因镜像配置错误、dns污染、tls握手卡死或镜像返回html（如人机验证）导致；需验证repo.packagist配置有效性、用curl直测镜像返回json、清缓存并排查网络链路。
“Unknown transport error”到底在报什么
这个错误不是 Composer 自己抛的，而是底层 cURL 或 PHP 的 stream wrapper 在建立连接时彻底失败——连 HTTP 状态码都拿不到，说明请求没发出去，或发出去后对方根本没响应。它和“Connection refused”“cURL error 7”本质一致，但更模糊，常出现在企业代理、DNS 污染、TLS 握手卡死或镜像源返回非 JSON 响应（比如人机验证 HTML 页面）时。
先确认是不是镜像配置写错了
90% 的“Unknown transport error”源于 repo.packagist 配置无效，导致 Composer 静默 fallback 到官方源，而你本地又连不上 packagist.org。
-
composer config -g repo.packagist输出必须是类似{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}的 JSON 对象；如果为空或报错，说明配置根本没存进去 - 必须用
-g全局设置，不加-g只改当前项目，换目录就失效 - URL 必须以
/结尾，https://mirrors.aliyun.com/composer（缺斜杠）会导致拼出/composerpackages.json这种非法路径 - 别写成
repos.packagist或repositories.packagist.org—— Composer 2.x 只认repo.packagist单数形式
快速验证镜像是否真可用
别信 composer config 输出，直接用 curl 测镜像本身是否返回合法 JSON：
curl -I https://mirrors.aliyun.com/composer/packages.json
必须看到 HTTP/2 200 和 Content-Type: application/json。如果返回 HTTP/1.1 302 或 HTML 页面（比如阿里云的人机验证），说明该镜像不适合自动化场景，得换腾讯云或华为云源。
- Windows 用户注意：PowerShell 的
curl是Invoke-WebRequest别名，要用curl.exe或改用cmd /c curl - CI/CD 环境常见问题：你用
root配的镜像，但实际跑命令的是www用户，得用sudo -u www composer config -g单独配 - 企业内网若走中间人代理，
curl -v会卡在* TLS handshake，此时可临时设composer config -g secure-http false辅助诊断（修好后务必恢复）
清缓存比重装 Composer 有用十倍
“Unknown transport error”往往和损坏的缓存文件强相关——Composer 下载中断后留了个半截 zip 或带 BOM 头的 JSON，下次重试直接复用，一读就崩。
- 先运行
composer clear-cache，然后手动检查$(composer config cache-dir)下是否还有残留.zip或packages.json文件 - Windows 用户还得删掉
%LOCALAPPDATA%\Composer\cache目录 - 如果仍失败，加
--no-cache强制跳过所有本地缓存：composer install --no-cache -vvv - 别急着删
vendor和composer.lock——这俩只影响 checksum 校验，和传输层错误无关
真正容易被忽略的是：这个错误从不单独出现，它总是和 DNS 解析失败、代理未生效、或镜像 URL 返回 HTML 页面绑定在一起。盯着报错本身没用，得回到网络链路一层层往下压。
