答案是inode耗尽而非磁盘空间不足；需先用df -i（Linux/macOS）或Get-PSDrive（Windows）确认缓存及/tmp分区inode使用率是否接近100%，再停掉所有composer进程，执行composer clear-cache，并可手动清理vcs/目录或禁用cache.vcs等非必要缓存类型。
为什么 composer install 突然报 No space left on device
不是磁盘真满了，而是 Composer 缓存目录（~/.composer/cache）积累了大量旧版本包、归档文件和未清理的 zip 解压残留。尤其在频繁切换分支、反复 composer update 或 CI 环境中，缓存体积可能达数 GB。
直接清空缓存：最安全有效的一步
运行 composer clear-cache 是首选操作——它会删除所有已下载的 zip 包、解压后的 dist 文件和 metadata 缓存，但不碰 vendor/ 和项目配置。执行后通常能释放 1–5 GB 空间。
常见误操作：
- 手动 rm -rf ~/.composer/cache 后忘记重建目录权限，导致后续命令报 Permission denied
- 在 root 下运行过 composer，缓存属主变成 root，普通用户再执行 clear-cache 会失败
- 先检查缓存路径：
composer config --global cache-dir - 确认属主：
ls -ld $(composer config --global cache-dir) - 若属主异常，用
sudo chown -R $USER:$(id -gn) ~/.composer/cache修复
删掉不用的全局包和历史版本
全局安装的工具（如 phpunit/phpunit、laravel/installer）常带多版本残留；composer global list 显示的是当前激活版本，但旧版仍躺在 ~/.composer/vendor/ 里。
手动清理更彻底：
- 进入 ~/.composer/vendor/
- 按包名分组，保留最新版（看 composer.json 中的 "version" 字段），删其余文件夹
- 或直接重装：先 composer global remove vendor/package，再 composer global require vendor/package:^x.y
注意：composer global update 不会自动删旧版，只更新当前锁定的版本。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
限制缓存大小或禁用 zip 缓存（长期策略）
默认缓存无上限，且同时存 zip + dist + metadata。可改用轻量模式：
- 禁用 zip 缓存（省最多空间）：
composer config --global cache-files-dir "" - 设缓存最大值（单位 MB）：
composer config --global cache-files-max-size "500M" - 关掉 dist 缓存（影响首次 install 速度）：
composer config --global cache-dir-dist false
这些配置写入 ~/.composer/config.json，下次 install 就生效。但要注意：禁用 zip 缓存后，每次 install 都要重新下载源码，对网络差的环境不友好。
真正卡住的时候，别纠结配置，先 composer clear-cache —— 多数情况这一步就解决问题。剩下那些“优化”只是防止下次再爆。
