Composer install 卡在“Content-Length mismatch”是因cURL下载时服务器Content-Length头与实际字节数不符，常见于网络不稳、代理中断、CDN异常或镜像同步滞后；解决方法为换国内镜像源（如阿里云）、执行composer clear-cache清空损坏缓存、再运行composer install --retry=3重试。
为什么 composer install 会卡在“Content-Length mismatch”？
这不是 Composer 本身的 bug，而是它用的 HTTP 客户端（默认是 cURL）在下载包时，服务器返回的 Content-Length 头和实际传输字节数对不上。常见于网络不稳定、代理中断、CDN 缓存异常或镜像源同步滞后。Composer 不会自动重试或断点续传，直接报错退出。
换源 + 启用重试是最快解法
国内用户遇到这个错误，八成是因为默认 packagist.org 直连超时或被干扰。换稳定镜像源后，配合 --retry 参数基本能绕过瞬时问题：
- 运行
composer config -g repo.packagist composer https://packagist.phpcomposer.com（已停用，改用https://packagist.org镜像如阿里云：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/） - 再执行
composer install --retry=3，让失败时最多重试 3 次 - 如果还失败，加
--no-cache跳过本地缓存，排除缓存污染可能
composer clear-cache 有时比重试更管用
Composer 会把下载的 zip 包缓存在 ~/.composer/cache/files/ 下，一旦缓存文件损坏（比如上次下载只写了一半），下次安装就会触发 Content-Length mismatch —— 因为它试图复用坏文件并校验长度。这时候重试毫无意义。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 先运行
composer clear-cache彻底清空缓存 - 确认
~/.composer/cache/files/目录为空后再重试安装 - 注意：清缓存不影响
vendor/或composer.lock，安全
真要断点续传？得绕开 Composer 自带下载器
Composer 本身不支持 HTTP 断点续传（Range 请求）。如果你反复卡在同一个大包（比如 laravel/framework 的 zip），可以手动下：
- 从
composer.lock里找到对应包的dist.url字段（例如"https://api.github.com/repos/laravel/framework/zipball/..."） - 用
wget -c或curl -C -手动下载到临时路径 - 再用
composer install --no-plugins --no-scripts跳过自动下载，最后把 zip 放进~/.composer/cache/files/对应子目录（需按 vendor/name/hash/ 命名）
这招有效但麻烦，只建议在 CI 环境或反复失败时手动干预。日常开发优先走换源 + 清缓存 + 重试组合。
