答案是inode耗尽而非磁盘块用光；需先用df -i或get-psdrive确认缓存及/tmp分区inode使用率是否接近100%，再停掉所有composer进程，执行composer clear-cache，并手动清理cache/vcs/和sys_get_temp_dir()中的残留文件。
缓存目录空间不足直接触发 No space left on device 错误
这不是磁盘块（block）真满了，而是 ~/.composer/cache 目录所在分区的 inode 耗尽——每个包版本、每个 Git 仓库克隆、每个 ZIP 解压残留都占一个 inode，小文件堆多了就卡死。报错时 df -h 显示还有几十 GB 空间，但 df -i 的 Use% 接近 100%，Composer 就会立刻失败。
cache/vcs/ 是真正的 inode 杀手，clear-cache 默认不碰它
composer clear-cache 只清 files/ 和 repo/，完全跳过 vcs/。而这个目录里存着每个包的 Git 克隆副本（比如 github.com/laravel/framework.git/），每次 composer update 或切换分支都会新增一个，旧的却不会自动删。一个中等项目积攒半年，vcs/ 下可能有上千个子目录，全占 inode。
- 手动清理：
rm -rf $(composer config --global cache-dir)/vcs - 长期禁用：
composer config --global cache.vcs false，后续所有包强制走--prefer-dist - 别在 root 下运行过 composer——否则
vcs/目录属主是 root，普通用户删不动
缓存里躺着大量“有效但无用”的旧 ZIP 包
composer clear-cache 不会删掉“仍能解压”的旧版 ZIP，只删损坏或过期条目。结果 cache/files/ 下每个包名目录里，可能同时存在 monolog/monolog/1.18.0/、1.25.0/、2.10.0/……这些 ZIP 文件加起来常占 2–4 GB，且全是冗余。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 按时间删：进入
~/.composer/cache/files，执行for d in */; do ls -t "$d" | tail -n +2 | xargs -I{} rm -rf "$d{}"; done - 按大小删：先
du -sh ~/.composer/cache/files/* | sort -hr | head -20找出最大几个包，再针对性清理 - 设上限防复发：
composer config --global cache-files-max-size "500M"
临时目录（sys_get_temp_dir）也是隐形炸弹
Composer 下载 ZIP、解压、生成 autoload 时，会把中间文件扔进 PHP 的临时目录（通常是 /tmp 或 C:\Windows\Temp）。如果 CI 构建频繁、没定期清理，这个目录也会吃光 inode 或磁盘空间，错误表现和缓存满一模一样——但 composer clear-cache 完全无效。
- 查位置：
php -r "echo sys_get_temp_dir();" - Linux/macOS：
sudo find $(php -r "echo sys_get_temp_dir();") -type f -mtime +7 -delete - Windows PowerShell：
Get-ChildItem "$env:TEMP" -Recurse | Where-Object {$_.LastWriteTime -lt (Get-Date).AddDays(-7)} | Remove-Item -Force
真正卡住的时候，别先改镜像或重装 PHP——先确认是磁盘块还是 inode 满，再盯紧 vcs/ 和 sys_get_temp_dir() 这两个地方，它们比 files/ 更容易被忽略。
