Composer缓存几天涨回2GB+，因默认cache-files-ttl为180天且vcs/目录不受控；需同时配置cache-max-size和cache-files-ttl触发GC，并禁用cache-vcs false以治本。
composer clear-cache 只能临时清空，真正管用的是配置自动回收策略——否则每次清理完几小时，缓存又涨回 2GB+。
为什么清完缓存，磁盘空间几天就又满了
Composer 默认不设上限，cache-files-maxsize 是 300MB，但 cache-files-ttl 是 180 天，意味着你三年前下载的 laravel/framework-9.0.0.zip 还躺在 ~/.composer/cache/files/ 里；更关键的是，vcs/ 目录完全不受 TTL 控制，每个 Git 克隆都完整保留，一个 Laravel 包的裸仓库就占 400MB，而 Composer 从不自动删它。
常见表现：composer clear-cache 后首次 composer install 很慢，但第二天 du -sh ~/.composer/cache 就又显示 1.7G——不是命令失效，是默认策略压根没打算“回收”。
设置 cache-max-size + cache-files-ttl 强制自动裁剪
这两项必须一起配，单设一个基本无效。Composer 2.5+ 支持按大小触发 GC，但前提是 TTL 到期文件已标记为可删，否则 GC 只会清“旧但未过期”的文件，起不到压缩作用。
- 运行
composer config --global cache-max-size "1G"（推荐 500M–1.5G，根据开发机空闲空间定） - 运行
composer config --global cache-files-ttl "604800"（单位秒，7 天足够覆盖日常迭代，比默认 180 天更激进） - 验证是否生效：
cat $(composer config --global cache-dir)/../config.json | grep -E "(max|ttl)"，应看到对应字段
注意：cache-max-size 不是硬限制，GC 每次只清理最久未访问的文件直到低于阈值，所以实际占用可能短暂略超，但不会持续膨胀。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
永久禁用 vcs 缓存：对绝大多数 PHP 开发者是安全的
除非你天天 composer require vendor/package:dev-main 或频繁 fork 修改包源码，否则 vcs/ 完全多余。它不加速安装，反而因完整克隆拖慢首次 update，且无法被 TTL 或 max-size 约束。
- 执行
composer config --global cache-vcs false - 立刻手动删掉已有缓存：
rm -rf ~/.composer/cache/vcs（Linux/macOS）或rd /s /q "%APPDATA%\Composer\Cache\vcs"（Windows） - 后续所有包强制走
--prefer-dist，即只下 ZIP，不再克隆 Git 仓库
副作用：以后装 dev- 分支时会变慢（因为要重新下载 ZIP），但换来的是磁盘稳定、clear-cache 真正有效、CI 构建更可预测。
检查 inodes 是否耗尽：磁盘明明有空间却报 No space left on device
这是 Composer 缓存最隐蔽的坑。~/.composer/cache/files/ 和 vcs/ 下动辄数万小文件，很容易打满 inodes，尤其 macOS APFS 或 WSL2 的默认分区。
- 先查：
df -i，如果某分区Use%接近 100%，哪怕df -h显示还有 20G 空间，也得按 inode 问题处理 - 清缓存后别立刻跑
composer install，先切缓存路径到 inode 充足位置：composer config --global cache-dir /tmp/composer-cache - /tmp 通常是 tmpfs（内存盘）或大 inode 分区，既能避坑，又能加快后续操作
长期看，cache-vcs false + cache-max-size 是治本之策；但遇到 No space left on device 时，df -i 必须是第一行命令，不是可选项。
