多数“磁盘空间不足”实为inode耗尽或临时目录塞满，需先用df -i确认；清缓存前须终止所有composer进程，再运行composer clear-cache；同时手动清理cache/vcs/和sys_get_temp_dir()中残留文件，并优先处理vendor/目录腾出真正空间。
直接运行 composer clear-cache 通常就能解决，但前提是问题真出在 Composer 缓存上——而多数“磁盘空间不足”报错，其实不是磁盘块（block）满了，而是 inode 耗尽，或者临时目录（sys_get_temp_dir()）塞爆了。
先确认是不是真磁盘满，还是 inode 满
报 No space left on device 却发现 df -h 显示还有几十 GB 剩余？大概率是 inode 用光了。Composer 缓存里每个包版本都建独立子目录（比如 ~/.composer/cache/files/monolog/monolog/1.27.0/），全是小文件，df -i 的 Use% 接近 100% 就会卡死。
- Linux/macOS：运行
df -i，重点看/tmp和缓存所在分区（比如/home） - Windows：PowerShell 中执行
Get-PSDrive C | Select-Object Used,Free，虽不直接显示 inode，但可辅助排除真实磁盘块是否真满 - 别跳过这步——清错地方只会浪费时间
停掉所有 composer 进程再清缓存
直接 rm -rf ~/.composer/cache 风险极高：IDE 内嵌的 Composer、后台未退出的 php composer.phar、残留锁文件，都会导致删一半就报 file_put_contents(): No space left on device，甚至损坏缓存索引。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 查进程：
ps aux | grep composer（Linux/macOS）或tasklist | findstr composer（Windows） - 杀干净：
kill -9 $(pgrep -f "composer")或手动结束对应 PID - 再跑
composer clear-cache——它会校验路径权限、跳过被占用项、安全删除无效/损坏/过期条目
手动清理 cache/vcs/ 和 sys_get_temp_dir() 里的残留
composer clear-cache 默认完全不管 cache/vcs/，但它恰恰是 inode 杀手；而 sys_get_temp_dir()（Windows 是 C:\Users\用户名\AppData\Local\Temp，Linux/macOS 是 /tmp）里堆积的 composer_*.zip、php*.phar 文件，往往比缓存还难察觉。
- 安全清 Git 仓库：
rm -rf $(composer config --global cache-dir)/vcs - 长期禁用它：
composer config --global cache.vcs false，之后所有包强制走--prefer-dist - 清临时目录：
find $(sys_get_temp_dir()) -name "composer_*" -mmin +60 -delete（Linux/macOS），或手动进 Windows Temp 文件夹删composer_*.zip
真正占空间的大头往往是 vendor/ 和临时解压
一个中等规模 Laravel 项目，vendor/ 动辄 300MB+，而缓存通常不到 50MB。想真正腾空间，得处理这里，但不能乱删：
- 先删
vendor/，再用composer install --no-dev（省掉测试依赖） - 临时腾空间可改用
composer install --prefer-dist --no-dev，跳过源码克隆，体积更小 - 注意
composer.lock必须存在，否则install会按composer.json重新解析依赖树，可能升版、出错
缓存只是其中一环。很多所谓“清了没用”的情况，根源根本不在缓存里——比如你刚在 C 盘装了十几个 Laravel 项目，每个都带完整 vendor/，那清缓存根本救不了命，得动手砍 vendor/，还得顺手清掉 %TEMP% 里那些看不见的 zip 解压残骸。
