Composer在CI构建机上clear-cache常无效，因默认跳过vcs/目录——单个Git裸仓库占300–800MB且生成海量inode，导致df -i达100%而du -sh显示缓存总量很小；应手动清理vcs/或禁用cache-vcs。
clear-cache 为什么在 CI 构建机上经常白忙活
它只清 files/、repo/、http/，默认跳过 vcs/——而后者单个 Git 裸仓库就占 300–800 MB，且每个都生成成千上万个 inode。构建机磁盘告警时，df -i 显示 inode Use% 99%，但 du -sh ~/.composer/cache 可能才 200 MB，问题根本不在缓存总量，而在 vcs/ 目录堆积。
常见错误现象：
- 执行
composer clear-cache后df -h空间没变，df -i仍是 100% - CI 日志卡在
Downloading阶段，报No space left on device，但磁盘块还有余量 - 手动
rm -rf ~/.composer/cache后首次composer install失败，提示Corrupted cache file
真正该做的不是“清不清”，而是：
- 先运行
df -i $(composer config --global cache-dir)定位 inode 消耗源头 - 确认是否被
vcs/主导：用du -sh $(composer config --global cache-dir)/vcs单独测 - 若
vcs/占比超 70%，直接手动删：rm -rf $(composer config --global cache-dir)/vcs/*（Linux/macOS）或rd /s /q "%APPDATA%\Composer\Cache\vcs"（Windows）
构建机上必须加的两个参数：--no-interaction 和 --dry-run
CI 环境无 TTY，composer clear-cache 默认会等待交互确认，直接 hang 住。更危险的是，它可能误删 NFS 挂载点或共享缓存卷——因为 composer config --global cache-dir 返回的路径未必是本地磁盘。
正确做法：
- 始终带上
--no-interaction：避免阻塞流水线 - 上线前必跑
--dry-run：输出将清理的真实路径，确认是否指向预期位置（比如不是/mnt/nfs/composer-cache） - 组合命令示例：
composer clear-cache --no-interaction --dry-run→ 确认无误后再去--dry-run
如果仍卡住，说明有后台进程锁着缓存目录：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- Linux/macOS：
lsof +D $(composer config --global cache-dir) - Windows：
handle.exe -p php.exe（需提前安装 Sysinternals 工具）
禁用 vcs 缓存比定期清理更治本
构建机通常只装 --prefer-dist 包，根本不需要 Git 克隆。继续保留 cache-vcs 只会不断生成新裸仓库，每次切分支、换源都新增一个 500 MB+ 的 vcs/ 子目录。
一劳永逸的做法是关掉它：
composer config --global cache-vcs false- 后续所有
composer install强制走 dist 包，不再创建vcs/目录 - 已有
vcs/内容不会自动删，需配合前面的手动清理
注意：禁用后首次 composer update 可能稍慢（要重新拉取 packages.json），但这是设计行为，不是故障。
别让 clear-cache 成为 CI 流水线的默认步骤
缓存本就是为加速复用而生。在构建机上每轮都 clear-cache，等于放弃本地加速，反而拖慢构建、增加镜像源压力，还掩盖真实瓶颈（比如 vendor/ 过大、镜像配置失效）。
真正该监控的指标是：
-
du -sh $(composer config --global cache-dir)是否持续 > 1.5 GB -
du -sh vendor/在项目根目录下是否 > 500 MB（这才是主要空间占用者） -
df -i中缓存所在分区是否长期 > 90% inode 使用率
复杂点在于：vcs/ 不清理，cache-files-maxsize 这类配置也无效——它只限制 files/ 新增包，不回收旧文件。构建机磁盘配额管理，本质是控制小文件数量，而不是盯着总字节数。
