直接运行 composer clear-cache 仅安全清理全局缓存中 files/、repo/、http 子目录，不删 vendor/ 或 vcs/；确认真实缓存路径需用 composer config --global cache-dir，超 1.5GB 且半年未用才值得清理，vcs/ 目录才是磁盘与 inode 杀手，需手动删除或禁用。
直接运行 composer clear-cache 能安全释放几百 MB 到 1.5 GB 空间，但多数人清完发现磁盘没变化——不是命令失效，而是缓存压根不占空间，或者你真正该删的是 vendor/ 目录。
怎么确认 Composer 缓存真占地方、路径对不对
别凭感觉删。缓存路径可能被 COMPOSER_CACHE_DIR、公司镜像或 composer config --global cache-dir 自定义覆盖，~/.composer/cache 或 %APPDATA%\Composer\Cache 不一定准确。
- 先查真实路径：
composer config --global cache-dir - Linux/macOS 查体积：
du -sh $(composer config --global cache-dir) - Windows 直接在资源管理器地址栏粘贴
%APPDATA%\Composer\Cache，右键 → “属性” - 不到 200 MB？基本不用管；超过 1.5 GB 且半年没碰老项目，才值得动手
为什么 composer clear-cache 清完空间没变多
最常见原因是：你真正想删的是项目里的 vendor/，不是全局缓存。一个中等 Laravel 项目 vendor/ 常超 300 MB，而缓存可能只有 42 MB。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
composer clear-cache只动cache-dir指向的目录，完全不碰vendor/、composer.lock、项目代码 - 有些团队把缓存挂到 NFS 或自建镜像目录，
clear-cache默认只清配置里那个路径，不会遍历其他挂载点 - 如果
du -sh显示缓存本身很小，却看到磁盘告警，立刻转向检查vendor/、日志目录、IDE 缓存或 Docker 镜像
为什么 vcs/ 目录才是真正的磁盘和 inode 杀手
~/.composer/cache/vcs/ 存的是 Git 裸仓库（含完整 .git），单个包克隆就吃掉 300–800 MB，且长期滞留、几乎不复用。而 composer clear-cache 默认跳过这个目录。
- 它还大量消耗 inode：每个包一个子目录 + 成千上万个 .git 对象文件，
df -i显示 Use% 接近 100% 时，No space left on device就是它导致的 - 禁用它最省事：
composer config --global cache.vcs false，后续所有 Git 包强制走--prefer-dist - 已存在的
vcs/可安全手动删：rm -rf ~/.composer/cache/vcs/*（Linux/macOS）或rd /s /q "%APPDATA%\Composer\Cache\vcs"（Windows）
清完为啥装包变慢、还报错？这不是 bug 是设计
缓存清空后首次 composer install 或 composer update 必然变慢，因为要重新下载所有 .zip 包和元数据。这不是故障，是预期行为。
-
repo/缺失 → 每次都要 HTTP 请求镜像源拉packages.json -
files/缺失 → 所有 dist 包重下，含大前端资产的包（如laravel/ui）最明显 - 报
file could not be downloaded或Failed to decode JSON？大概率是网络、代理或源配置问题，不是缓存脏了 - 刚切了阿里云镜像但还 404？先确认
composer config repo.packagist false已生效，否则清缓存白搭
真正容易被忽略的是 vcs/ 和 inode 耗尽——尤其 WSL 或 macOS APFS 下，df -h 显示还有空间，df -i 却爆满，这时候删 files/ 没用，得清 vcs/ 或禁用它。
