代理软件拦截 https 请求导致 composer install 卡死，根本原因是代理未正确配置 https 转发、响应体被篡改或 url 拼接错误，而非镜像配置问题；需分别检查代理的 https 支持、缓存/重写模块、镜像 url 末尾斜杠及仓库顺序，并通过 curl 和 composer config 验证配置生效。
代理软件拦截 HTTPS 请求导致 composer install 卡死
不是镜像配置错了，是代理（如 Clash、Surge、Fiddler）把 Composer 的 HTTPS 请求劫持或转发失败了。现象是 composer install -vvv 日志卡在 Loading composer repositories，既不报错也不超时，curl -I https://mirrors.aliyun.com/composer/packages.json 却能秒回 200。
- 根本原因：Composer 默认走 HTTPS，而多数代理默认只监听 HTTP 流量；HTTPS 请求没被代理捕获，就 fallback 到直连 —— 在企业内网或 DNS 污染环境下等于失败
- 验证方式：临时关掉代理再跑
composer install，如果立刻开始下载，说明就是代理没配好 HTTPS 转发 - 解决办法不是换镜像，而是补全代理配置：
composer config -g http-proxy http://127.0.0.1:7890和composer config -g https-proxy http://127.0.0.1:7890（注意两个都得设，且https-proxy值仍用http://开头） - Clash 用户需确认规则中未将
mirrors.aliyun.com或packagist.org误判为“直连”，可在 Profiles → Rule 中临时加一条DIRECT规则测试
代理返回篡改响应体引发 hash verification failed
某些代理（尤其带缓存或重写功能的）会悄悄修改包 ZIP 的二进制内容，或在响应头里塞入 Transfer-Encoding: chunked 导致 Composer 计算 dist.sha256 失败，报错 hash verification failed。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 这不是镜像问题，也不是网络丢包，是代理层污染了原始响应体
- 典型现象：同一命令在无代理环境能成功，在代理下反复失败，且
vendor/里解压出的文件明显损坏（比如autoload_classmap.php末尾缺括号） - 快速验证：用
curl -sL https://mirrors.aliyun.com/composer/p2/monolog/monolog.json | jq -r '.packages."monolog/monolog"."2.10.0".dist.sha256'取到哈希值，再手动下载对应 ZIP，用sha256sum xxx.zip对比 —— 若不一致，就是代理动了手脚 - 临时绕过：设
composer config -g secure-http false关 SSL 校验（仅调试用，完事后务必恢复），或直接禁用代理的缓存/重写模块
代理与中文镜像 URL 中的斜杠冲突
镜像 URL 少写末尾 /，加上代理后会拼出非法路径，比如 https://mirrors.aliyun.com/composerpackages.json（中间缺斜杠），返回 404，但 Composer 不报具体 URL 错误，只显示 Could not fetch packages.json。
- 代理本身不改 URL，但它会让这个拼接错误更隐蔽 —— 因为请求先发给代理，再由代理转发，日志里看不到原始拼接过程
- 必须确保镜像配置完整：
composer config -g repo.packagist '{"type":"composer","url":"https://mirrors.aliyun.com/composer/"}'（注意末尾/和 JSON 格式） - 验证是否生效：运行
composer config -g repo.packagist，输出必须是完整 JSON 对象，不能是字符串或 null - 若代理开着，
composer install -vvv日志中应出现类似GET https://mirrors.aliyun.com/composer/packages.json的行 —— 没出现，说明配置根本没生效
代理环境下的私有包 + 中文镜像双重 fallback 失效
项目同时用了 path 本地仓库和阿里云镜像，又开了代理，结果 composer install 报 Could not find package xxx，但 composer show xxx 能查到 —— 这是代理干扰了仓库查找顺序。
- 原因：Composer 按
repositories数组顺序查找，先向镜像发请求；代理若对镜像域名返回 404，Composer 就终止，不再尝试后面的path条目 - 关键点：代理可能对镜像域名做了 DNS 劫持或路由策略，导致本该 404 的请求变成了超时或空响应，Composer 误判为“服务不可达”而非“包不存在”，于是不 fallback
- 解决路径：把
path仓库移到repositories数组最前面，并显式禁用 packagist.org："packagist.org": false（放在repositories同级） - 代理调试建议：用
curl -v https://mirrors.aliyun.com/composer/packages.json看实际响应头和状态码，确认代理是否返回了非标准 404（比如 502 或空 body）
