“No space left on device”但df -h仍有空间，90%以上是inode耗尽，需先运行df -i检查/tmp和~/.composer/cache所在分区Use%，≥95%即确认；再执行composer clear-cache、禁用cache-files-ttl和cache-source，并指定TMPDIR避开inode紧张路径。
报“No space left on device”但df -h还有空间？先查inode
这不是镜像源的问题，而是 Composer 在写缓存或解压时被系统拒绝——file_put_contents(): No space left on device 这类错误，90% 以上是 inode 耗尽，不是磁盘块用光。尤其在包发布场景（如 composer publish 或私有镜像同步），Composer 会大量生成哈希目录、ZIP 包、dist 文件和 repo 元数据，每个都占一个 inode。
必须立刻执行：df -i，重点看 /tmp 和 ~/.composer/cache 所在分区的 Use%。若 ≥95%，就是它了。macOS（APFS）、CI runner、Docker 容器里特别常见。
- 验证缓存路径：
composer config --global cache-dir - 检查该路径所在分区 inode 使用率：
df -i $(composer config --global cache-dir) - 别只信
df -h—— 它完全不显示 inode 状态
清理前先停掉所有 composer 进程
包发布卡在 “Downloading” 或 “Writing lock file” 阶段，往往是因为上次失败没清理临时文件，导致 Composer 反复尝试写入同一个损坏缓存项。它不会跳过，也不会报具体哪个包失败。
- Linux/macOS：
killall -u $USER composer php或pkill -f "composer\|php.*\.phar" - Windows PowerShell：
Get-Process | Where-Object {$_.Path -match "composer|php"} | Stop-Process - IDE（如 PHPStorm）内嵌的 Composer 进程也要关掉，否则清理后仍可能冲突
安全清缓存 + 切换临时目录
composer clear-cache 是唯一推荐的起点。它会校验、去重、删损坏项，保留仍被本地项目引用的有效包；手动 rm -rf ~/.composer/cache 后立刻跑发布，反而可能瞬间打满 inode 或触发权限错误。
- 执行前确认权限正常：
ls -ld $(composer config --global cache-dir)，若含Permission denied，说明部分子目录属主不是当前用户（比如曾用sudo composer） - 清理后首次发布稍慢属正常，尤其用了阿里云/腾讯云镜像
- 临时切到 inode 充足路径：
composer config --global cache-dir /tmp/composer-cache（前提是/tmp分区 inode 充足） - 更关键的是指定 PHP 临时目录：
TMPDIR="/mnt/data/tmp" php -d sys_temp_dir="/mnt/data/tmp" composer publish
禁用非必要缓存类型治本
默认 Composer 会同时存 ZIP 包、解压后的源码、repo 元数据——其中 ZIP 和 source 缓存最占 inode。包发布不需要这些，关掉能大幅降低小文件膨胀速度。
- 禁用 dist 缓存（.zip/.tar）：
composer config --global cache-files-ttl 0 - 禁用 source 缓存（git clone 后的源码）：
composer config --global cache-source false - 保留 repo 缓存即可：
composer config --global cache-repo true（只存 JSON 元数据，体积小且加速解析） - CI 或私有镜像发布脚本中，直接加
--no-cache参数：composer publish --no-cache --no-interaction
真正容易被忽略的是：PHP 的 sys_get_temp_dir() 路径（通常是 /tmp）比 cache-dir 更容易堆积 composer_*.zip 和 php*.phar，且不受 Composer 配置控制——必须通过环境变量或 -d sys_temp_dir 单独指定。
