composer clear-cache 默认不清理 vcs/ 目录，而该目录单个 git 克隆就占 300–800 mb，是磁盘空间主要占用者；应先用 composer config --global cache-dir 确认路径，再用 du -sh $(composer config --global cache-dir)/vcs 检查其大小，必要时手动删除或禁用 cache-vcs。
直接运行 composer clear-cache 能释放几百 MB 到 1.5 GB 不等的空间，但**它默认不碰 vcs/ 目录**——而这个目录才是吃掉磁盘的主力，单个 Laravel 或 Symfony 的 Git 克隆缓存就常达 300–800 MB。
怎么确认缓存真占地方、路径对不对
别猜默认路径，composer config --global cache-dir 才是唯一可信来源。公司镜像、自定义 COMPOSER_HOME 或 COMPOSER_CACHE_DIR 都可能把缓存挪到非预期位置。
- Linux/macOS：运行
du -sh $(composer config --global cache-dir)看真实体积；如果输出是4.0K或提示No cache files to delete，说明缓存基本空了，清也白清 - Windows：在资源管理器地址栏粘贴
%APPDATA%\Composer\Cache，右键“属性”看大小；若不到 200 MB，基本可排除它是磁盘告警主因 - 注意：
du -sh ~/.composer/cache/vcs/单独查这个子目录，常能发现占了总缓存 70% 以上
为什么 composer clear-cache 后还是满？重点盯 vcs/
composer clear-cache 默认只清 files/、repo/、http/，跳过 vcs/——这是设计，不是 bug。但它让大量 Git 裸仓库长期滞留，每个都带完整 .git，文件数动辄上万，极易耗尽 inodes（尤其 WSL/macOS APFS）。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- Linux/macOS：清完立刻补一句
rm -rf ~/.composer/cache/vcs/（注意尾部斜杠，vcs/比vcs更安全） - Windows：用 CMD 运行
rd /s /q "%APPDATA%\Composer\Cache\vcs"；PowerShell 可能因执行策略失败，别硬扛 - CI 或小磁盘机器建议永久禁用：
composer config --global cache-vcs false，后续所有 Git 包强制走--prefer-dist
清完为啥装包变慢？这不是故障，是代价
缓存清空后首次 composer install 或 composer update 必然变慢，因为要重下所有 .zip 和 packages.json。这不是命令出错，是设计使然：
-
repo/packagist.org/缺失 → 每次都要 HTTP 请求拉元数据，卡在Loading composer repositories -
files/缺失 → 所有 dist 包重下，含大资产的包（如laravel/ui）最明显 - 别频繁清理：每月一次或仅在
df -h报警时执行；日常维护优先composer self-update，新版对缓存压缩更聪明
真正吃 C 盘的往往不是缓存本身，而是项目里反复 composer install 留下的旧 vendor/、没删干净的 node_modules/，或者 Composer 在系统临时目录（sys_get_temp_dir()）解压 ZIP 时爆掉的碎片文件——这些 clear-cache 一概不管。
