composer update --no-cache 会强制绕过所有缓存（files/repo/vcs），每次重拉元数据、重clone Git仓库、重解压ZIP包，导致磁盘I/O和空间占用暴增，仅适用于调试一致性问题，不适合常态监控；真正监控VCS缓存行为应实时观察~/.composer/cache/vcs/目录的大小与inodes变化。
composer update --no-cache 会暴增磁盘写入，但不是监控手段
想“监控”VCS 资源拉取时的缓存行为，不能靠 --no-cache——它只是强制绕过所有缓存，每次重 clone、重 fetch、重解压，导致磁盘 I/O 和空间占用瞬间飙升，适合调试一致性问题，不适合观察常态行为。真正要监控，得盯住 ~/.composer/cache/vcs/ 目录的实时变化。
怎么实时观察 vcs 缓存目录的磁盘增长
VCS 缓存（Git/SVN 等裸仓库）默认存在 ~/.composer/cache/vcs/（Linux/macOS）或 %APPDATA%\Composer\Cache\vcs\（Windows），每个私有包对应一个子目录，结构为 git@host.com:vendor/name.git/ 或类似路径。监控的关键是看它是否在 composer update 过程中持续写入新对象。
- Linux/macOS：运行
watch -n 1 'du -sh ~/.composer/cache/vcs/* 2>/dev/null | sort -hr | head -5'，每秒刷新一次前五大 VCS 缓存目录大小 - Windows（PowerShell）：用
while($true){ Get-ChildItem $env:APPDATA\Composer\Cache\vcs -Directory | ForEach-Object { [PSCustomObject]@{Name=$_.Name;Size=(Get-ChildItem $_.FullName -Recurse -File | Measure-Object Length -Sum).Sum} } | Sort-Object Size -Descending | Select-Object -First 5; Start-Sleep -Seconds 1 } - 注意：
vcs/下的目录名常含@、:、/等字符，直接ls或资源管理器可能显示异常，优先用命令行
为什么 vcs 缓存体积会异常大，且难清理
vcs/ 目录里存的是 Git 的裸仓库（.git），包含完整历史、所有分支、所有 tag 和所有对象（blobs/trees/commits）。哪怕你只 require 了 dev-main，Composer 也会 fetch 全量 refs 并保留全部 objects——这是 Git 协议限制，不是 Composer 能跳过的。
- 常见膨胀原因：
git gc未自动触发、私有仓库长期未git repack -ad、包含大文件（如二进制 assets、log dump）被误提交 -
composer clear-cache会删掉整个vcs/目录，但下次 update 仍会全量重建；手动清理更安全：rm -rf ~/.composer/cache/vcs/*后再跑composer update，Git 会重新 fetch，但不会继承旧垃圾 - 别碰
vcs/下单个子目录里的objects/pack/文件——它们被 Git 引用，删了会导致后续 fetch 失败或报error: object file .git/objects/xx/yy is empty
如何判断某个私有包是否在反复拉取 vcs 缓存
不是所有私有包都会高频触发 VCS 拉取。关键看 composer.json 中的 require 版本约束是否宽松，以及该包是否有频繁变动的分支策略。
- 如果
"your-vendor/private": "dev-develop"，每次composer update都会git fetch origin develop并更新本地 ref，即使没新 commit，也可能因 Git 的 loose objects 积累而缓慢增长 - 若用
"your-vendor/private": "1.2.0"（固定版本），Composer 通常只 fetch 一次，后续复用vcs/缓存，除非你清了缓存或换镜像源 - 验证方法：在
composer update -v输出里搜Executing command (CWD): git fetch或Cloning into，确认是否对同一仓库重复执行
监控 VCS 缓存增长容易忽略一点：它不体现为单个大文件，而是数万个小对象（.git/objects/ab/cdef123...），df -i 显示 inodes 接近 100% 时，du -sh 可能只报几百 MB，但磁盘已无法写入新文件。
