“Content-Length mismatch”不是 Composer 的错，而是网关、代理或 CDN 转发时写错 Content-Length 头或截断响应体所致；Composer 仅严格校验并报错，不重试、不降级；常见于企业防火墙、校园网及云服务商负载均衡器，尤其 HTTP/2 或 chunked 编码下易触发。
为什么“Content-Length mismatch”不是 Composer 的错
这个错误本质是网关、代理或 CDN 在转发 HTTP 响应时，把 Content-Length 头写错了，或者中途截断了响应体——Composer 只是忠实地比对 header 和实际字节数，发现不一致就立刻报错退出。它不会重试，也不会忽略校验，更不会自动降级协议。常见于企业防火墙、校园网出口、某些云服务商的负载均衡器，尤其是启用 HTTP/2 或 chunked 编码时更容易触发。
换镜像源 + 强制 HTTP/1.1 是最短路径
国内用户约 80% 的此类问题，根源是 packagist.org 经过中间网关后被污染，而非本地配置问题。阿里云、腾讯云镜像做了 TLS 加速和响应体缓存，基本规避了这类截断。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 执行
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 禁用 HTTP/2（某些网关对 HTTP/2 的
Content-Length处理有 bug）：composer config -g http.version 1.1 - 验证是否生效：运行
composer install -vvv，观察下载 URL 是否已变成https://mirrors.aliyun.com/...
清缓存比重试更重要
一旦缓存目录里存了被截断的 ZIP，Composer 下次会直接复用并校验失败，此时反复重试只会循环报 Content-Length mismatch。必须先清掉坏文件。
- 运行
composer clear-cache，它会清空~/.composer/cache/files/下所有 ZIP - 确认缓存目录为空：
ls -la $(composer config cache-dir)/files/应无输出 - 再跑
composer install --no-cache，强制跳过缓存走全新下载，验证是否还出错
临时绕过校验要谨慎但有时必要
仅限可信内网环境或 CI 调试阶段，不建议长期开启。它不修复网络问题，只是让 Composer 跳过长度校验这一步。
- 关闭 HTTPS 安全检查（仅测试用）：
composer config -g secure-http false - 配合
--prefer-dist强制走压缩包分发路径，避免 Git 协议被干扰引发的连锁校验失败 - 注意：
secure-http false会让 Composer 接受 HTTP 源，存在中间人风险；生产环境务必关掉
