答案是inode耗尽而非磁盘空间不足；需先用df -i（linux/macos）或get-psdrive（windows）确认/tmp及缓存分区inode使用率≥95%，再停掉composer进程、执行clear-cache，可手动清理vcs/目录或重定向tmpdir至大容量分区。
“No space left on device”但df -h还有几十GB？先查inode
这不是磁盘块真满了，而是临时目录的 inode 耗尽——Composer 缓存和 ZIP 解压过程会生成海量小文件（比如 vcs/ 下每个 Git 仓库子目录、files/ 里成千上万个 *.zip），尤其在 macOS APFS、Docker 容器或某些云主机上极易触发。直接删文件前，必须确认问题根源：
- Linux/macOS：运行
df -i，重点看/tmp和~/.composer/cache所在分区的Use%是否 ≥95% - Windows：PowerShell 中执行
Get-PSDrive C | Select-Object Used,Free辅助判断（虽不显示 inode，但可排除磁盘块满的假象） - 别跳过验证：哪怕
df -h显示剩余 20GB，df -i一满，file_put_contents(): No space left on device就必然报错
清理前必须停掉所有 composer 进程
直接 rm -rf ~/.composer/cache 风险极高——IDE 内嵌的 Composer、后台未退出的 php composer.phar、残留锁文件，都会导致删一半卡死，甚至损坏缓存索引。安全清理分三步：
- 查进程：
ps aux | grep composer（Linux/macOS）或tasklist | findstr composer（Windows） - 杀干净：
kill -9 $(pgrep -f "composer")或手动结束对应 PID - 再跑
composer clear-cache——它会校验路径权限、跳过被占用项、安全删除无效/损坏/过期条目
若输出含 Permission denied，说明部分子目录属主不是当前用户（比如曾用 sudo composer），需先修复权限。
只删真正占空间又无用的 ZIP 包，别碰元数据
composer clear-cache 不会删“有效但陈旧”的包（比如你三年前装过的 monolog/monolog 1.18.0），这类冗余 ZIP 最占空间又最无用。手动精简更高效：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 进缓存 ZIP 目录：
cd $(composer config --global cache-dir)/files - 删 90 天前的 ZIP：
find . -name "*.zip" -mtime +90 -delete - 删整个旧版包目录（按修改时间保留最新）：
for d in */; do ls -t "$d" | tail -n +2 | xargs -I{} rm -rf "$d{}"; done - 可安全清
vcs/目录：rm -rf $(composer config --global cache-dir)/vcs（禁用后 Composer 自动 fallback 到 dist 安装）
别碰 repo/packagist.org/：这是核心元数据快照，删了首次 update 会卡很久。
临时目录重定向比清理更治本
改 sys_get_temp_dir() 全局行为会影响其他 PHP 应用，但可以只对 Composer 生效——通过环境变量覆盖，避免反复清理：
- Linux/macOS：启动前加
TMPDIR=/path/to/big-disk/tmp composer install - Windows：命令行中先执行
set TMPDIR=D:\big-tmp，再运行composer install - 验证路径：
php -r "echo sys_get_temp_dir();"必须输出你指定的新路径
注意：不要用 rm -rf /tmp —— 可能误删其他进程正在使用的临时文件。临时目录重定向是唯一能同时规避 inode 耗尽和磁盘块不足的通用解法，尤其适合 CI 环境或低配服务器。
