“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 源，存在中间人风险；生产环境务必关掉

真正卡住的时候，别盯着 timeout 或 memory_limit 调参数——网关层截断是协议层问题，调高超时只会让你等更久，看到更多重复错误。先换源、清缓存、关 HTTP/2，三步做完再看日志，大概率就过了。