答案是inode耗尽而非磁盘空间不足。composer在缓存目录和/tmp中大量创建小文件，占满inode，尤其在macos、docker及低配云主机上易发；需用df -i检查，杀进程后执行composer clear-cache并禁用cache.vcs。
Composer报“No space left on device”但df -h还有空间？先查inode
这不是磁盘块满了，而是inode耗尽。Composer在缓存目录（如~/.composer/cache/files/、vcs/）和/tmp里大量创建小目录和文件，每个都占一个inode。macOS（APFS）、Docker for Mac/Windows、低配云主机尤其容易触发。
立刻验证：
- Linux/macOS：运行 df -i /tmp 和 df -i $(composer config --global cache-dir)
- 若任意输出中 Use% ≥ 95%，且 Inodes 可用数为 0，就是它了
- Windows 用户请改用 PowerShell 查磁盘块（Get-PSDrive C），但 inode 无法直接查，需默认按此问题处理
- 别信错误信息字面意思——
No space left on device在中文环境高频指向 inode，不是磁盘容量 -
composer install卡在Downloading或Extracting archive阶段，基本可锁定 - CI 构建机、Docker 容器内、NFS 挂载的缓存路径，inode 更容易爆满
清缓存前必须杀光所有 composer 进程
直接 rm -rf ~/.composer/cache 极危险。IDE 内嵌的 Composer、后台未退出的 php /path/to/composer.phar、残留锁文件，都会导致删到一半就卡死，甚至损坏缓存索引，后续仍报 file_put_contents(): No space left on device。
安全做法：
- Linux/macOS：ps aux | grep composer → 找出 PID → kill -9 PID（或 kill -9 $(pgrep -f "composer")）
- Windows：tasklist | findstr composer → 记下 PID → taskkill /PID XXXX /F
- 确认无残留后，再跑 composer clear-cache
-
composer clear-cache会校验路径权限、跳过被占用项、只删无效/过期条目，比手动删更稳 - 它默认不清理
vcs/目录——那是 inode 最大杀手，必须单独处理 - 若
clear-cache输出含Permission denied，说明部分子目录属主是root，得先chown -R $USER:$USER $(composer config --global cache-dir)
禁用 cache.vcs 是一劳永逸的关键操作
~/.composer/cache/vcs/ 存的是 Git 裸仓库，每个包一个仓库，动辄数万个小文件 + 数百 MB 空间，是 inode 和磁盘双料消耗源。但对绝大多数项目完全非必需——禁用后 Composer 自动 fallback 到 --prefer-dist（下载 ZIP 包），速度更快、更轻量。
执行：composer config --global cache.vcs false
然后手动清掉已有内容：
- Linux/macOS：rm -rf $(composer config --global cache-dir)/vcs/
- Windows：rd /s /q "%APPDATA%\Composer\Cache\vcs"
- 禁用后所有
composer install/update默认走 dist 流程，无需额外参数 -
cache/repo/别碰——删了会导致首次composer update卡很久 - 如果公司镜像源强制走 vcs（比如私有 GitLab + mirror），需联系运维关掉镜像的 vcs 同步开关
临时目录和缓存路径别踩这些坑
Composer 默认用 /tmp 解压 ZIP，而很多系统（尤其是 macOS、某些 Docker Desktop 版本）会定时清空或限制其 inode。同时，缓存路径若落在机械硬盘、overlay2 文件系统或 NFS 上，也会加剧问题。
推荐动作：
- 把缓存迁移到 SSD：composer config --global cache-dir /mnt/ssd/composer-cache
- 或用内存盘（Linux）：sudo mount -t tmpfs -o size=2G tmpfs /mnt/ramdisk → composer config --global cache-dir /mnt/ramdisk
- 绝对不要设成 /tmp 或 /var/tmp，避免被系统自动清理
- Docker 环境里，别用
-v $(pwd)/vendor:/app/vendor—— macOS/Windows 的文件桥接会让stat()延迟飙升，触发超时或静默卡死 - 开发用命名卷：
docker run -v composer-vendor:/app/vendor；CI 构建阶段务必在容器内跑composer install - 软链接项目目录下运行
composer install时，COMPOSER_HOME必须设为绝对路径（如/home/user/.composer），不能依赖~或当前路径解析
真正麻烦的从来不是“怎么清”，而是“清完又被谁悄悄写回去”。cache.vcs 关不掉，下次 composer update 就会原样复活；/tmp 没换路径，CI job 一跑又堆几千个临时目录；Docker 挂载方式不对，本地调试永远慢半拍。这些点漏掉一个，问题就会循环出现。
