答案是inode耗尽而非磁盘块用光；需先用df -i（Linux/macOS）或Get-PSDrive（Windows）确认缓存及/tmp分区inode使用率是否接近100%，再停掉所有composer进程，执行composer clear-cache，并手动清理cache/vcs/和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，但可辅助排除真实磁盘块是否真满
不查这步就动手清，90% 情况下白忙活
停掉所有 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/ 和旧 ZIP 包
composer clear-cache 默认完全不管 cache/vcs/，而这个目录单个 Git 裸仓库就占 300–800 MB，含上万小文件，是 No space left on device 的高频原因；它也不删“有效但陈旧”的 ZIP 包（比如三年前装过的 monolog/monolog 1.18.0），这类冗余最占空间又最无用。
- 安全清 Git 仓库：
rm -rf $(composer config --global cache-dir)/vcs - 禁用它（治本）：
composer config --global cache.vcs false，之后所有包强制走--prefer-dist - 删 90 天前的 ZIP：
find $(composer config --global cache-dir)/files -type d -mtime +90 -delete
别忘了 sys_get_temp_dir() 这个隐形炸弹
Composer 解压 ZIP、生成 autoload、跑脚本时全往 sys_get_temp_dir() 塞文件，默认是 /tmp（Linux/macOS）或 %TEMP%（Windows）。这个目录默认不参与 clear-cache，里面堆积的 composer_*.zip、php*.phar 文件极难察觉，但极易耗尽 inode。
查路径：php -r "echo sys_get_temp_dir();"
删文件：find $(php -r "echo sys_get_temp_dir();") -name "composer_*" -delete 2>/dev/null
真正卡住同步的，往往不是镜像源本身，而是这三个地方：缓存目录的 inode、vcs/ 的裸仓库、临时目录里的残骸——三者任何一个爆满，composer install 或 update 都会静默挂起，且错误提示毫无指向性
