composer clear-cache仅解决缓存污染导致的安装失败、版本错乱或卡住问题，对依赖冲突、php版本不匹配、语法错误无效；它清除~/.composer/cache下repo/files/http全部内容，不影响vendor/composer.lock/镜像配置。
composer clear-cache 能清掉本地已下载的包压缩包和元数据，但不是万能的“一键修复”——它只解决缓存污染导致的安装失败、版本错乱或 composer install 卡住这类问题，对依赖冲突、PHP 版本不匹配、composer.json 语法错误完全无效。
什么时候必须用 composer clear-cache
缓存出问题的典型表现是：明明换了源或更新了包，composer update 却还是拉旧版；或者报类似 Could not load package xxx in http://repo.packagist.org 这种看似网络问题、实为本地缓存校验失败的错误。
- 刚切换了国内镜像（比如从 packagist.org 换成阿里云镜像），但
composer require仍走原地址 -
composer update提示某包 “has no versions matching”，而你在 packagist.org 上明明能看到最新版 - 反复执行
composer install卡在Loading composer repositories阶段，且~/.composer/cache/下有大量 .zip 或 .json 文件
composer clear-cache 的实际行为和副作用
它删的是 ~/.composer/cache/（Linux/macOS）或 %APPDATA%\Composer\Cache\（Windows）下的全部内容，包括：repo/（包元数据）、files/（.zip 包）、http/（HTTP 响应缓存）。下次运行 composer install 或 update 会重新下载，首次耗时变长，但后续不受影响。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 不会动项目里的
vendor/、composer.lock或全局配置config.json - 不会重置你设的镜像源（
composer config -g repo.packagist.org ...的设置还在） - 如果公司用了私有 Packagist（如 Satis 或 Private Packagist），缓存清理后首次请求会触发完整元数据同步，可能稍慢
比 clear-cache 更常需要的操作
很多人以为清缓存能解决所有 Composer 问题，其实更常见的是配置或环境问题。遇到异常，优先检查这些：
- 确认 PHP 版本满足要求：
php -v和composer show --platform对得上composer.json里的"php": "^8.1" - 检查是否误启用了 xdebug：
composer diagnose会提示 “xdebug is enabled”，此时先php -d xdebug.mode=off $(which composer) install - 私有包认证失效？
composer config -g github-oauth.github.com xxx的 token 过期了，clear-cache不会帮你重登录 - Windows 下路径太长导致解压失败？那是
vendor/权限或系统限制，清缓存没用
缓存本身很老实，出问题往往是因为你刚改过源、换过 PHP、或手动动过 ~/.composer/cache/ 里的文件——这时候清是有效的。但只要没动过这些，突然报错，大概率是别的地方卡住了。
