composer 报“no space left on device”是因容器内挂载卷或/tmp临时空间不足，需区分宿主机挂载卷满（df -i/du排查）与容器/tmp tmpfs过小（挂载宿主/tmp或增大tmpfs），并优化缓存（禁用vcs缓存、挂载持久化cache、定期清理）。

Composer 编排本身不管理容器内部磁盘空间——报错“No space left on device”出现在 容器内运行 Composer 命令时（比如 docker-compose run --rm php composer install），根源是容器所挂载的宿主机路径或容器临时文件系统（如 /tmp）空间/Inode 耗尽，而非 Docker Compose 的编排逻辑问题。

先确认是容器内哪部分空间不足

容器内空间问题分两类，必须区分处理：

• 宿主机挂载卷写满：比如 volumes: - ./app:/var/www/html，宿主机 ./app 所在分区 inode 或磁盘块已满 → 需在宿主机上清理（df -i 查 inode，du -sh ./* | sort -hr | head -10 找大目录）
• 容器自身临时空间不足：PHP 运行 Composer 时依赖 sys_get_temp_dir()（Linux/macOS 默认 /tmp，Windows 默认 %TEMP%），而容器默认的 /tmp 是内存挂载（tmpfs），大小有限（常为 64MB–1GB）→ 容易因解压 ZIP、生成 autoload 文件失败

给容器分配足够临时空间

避免 tmpfs 空间硬限制，推荐两种方式：

minimax-mcp-docker版（适配极空间）

MiniMax 图片理解 + 网络搜索 MCP 工具。适配 Docker 环境（极空间等），支持图片 OCR 识别、图像内容理解、网络搜索。API Key 安全存储在本地 credentials 文件，不暴露在代码中。

下载

• 挂载宿主机一个专用临时目录：
  volumes:
  - /path/on/host/tmp:/tmp
  并确保该路径所在分区有余量（df -h /path/on/host/tmp）
• 改用更大 tmpfs（仅限短期调试）：
  tmpfs:
  - /tmp:rw,size=2g,exec

优化 Composer 在容器内的缓存行为

容器每次重建都重走缓存流程，极易堆积小文件耗尽 inode。关键动作：

• 禁用 VCS 缓存（最省 inode）：
  构建镜像时执行 composer config --global cache.vcs false
• 挂载持久化缓存目录（避免重复下载）：
  volumes:
  - ~/.composer/cache:/root/.composer/cache
  （注意：宿主机该路径需提前创建并属主匹配容器用户）
• 构建阶段加 --no-cache 或定期清理：
  docker-compose run --rm php sh -c "composer clear-cache && composer install"

检查并修复宿主机层面的 inode 耗尽

尤其当多个容器共享同一挂载点（如 CI/CD 中频繁 composer update）时，~/.composer/cache/vcs/ 和 /tmp 下海量 Git 克隆目录会快速吃光 inode：

• 查 inode 使用率：df -i /path/to/mount（若 IUse% ≥ 95%，立即处理）
• 定位小文件密集目录：find /path/to/mount -type d -name "vcs" -o -name "cache" | xargs ls -lA | head -20
• 安全清理旧缓存：
  rm -rf $(composer config --global cache-dir)/vcs
find $(composer config --global cache-dir)/files -name "*.zip" -mtime +30 -delete