composer无内置命令查缓存体积，需用系统命令：linux/macos执行du -sh $(composer config --global cache-dir)/files// | sort -hr | head -20，windows用powershell遍历files目录统计各hash子目录大小并排序。
怎么直接看到缓存里谁占空间最大
Composer 没有内置命令能列出「缓存中各包体积排名」，因为缓存目录 files/ 里存的是按 hash 组织的压缩包，不是按包名平铺的。你得自己进目录查——但不用解压，只看文件大小和路径就能判断。
先确认真实缓存路径：composer config --global cache-dir。默认 Linux/macOS 是 ~/.composer/cache，Windows 是 %APPDATA%\Composer\Cache。
- Linux/macOS：运行
du -sh $(composer config --global cache-dir)/files/*/* | sort -hr | head -20—— 这会列出files/下所有包版本（vendor/name/hash/）的实际磁盘占用，按大小倒序 - Windows（PowerShell）：用
Get-ChildItem "$(composer config --global cache-dir)\files" -Recurse -Directory | ForEach-Object { [PSCustomObject]@{Path=$_.FullName; Size=(Get-ChildItem $_.FullName -File | Measure-Object Length -Sum).Sum} } | Sort-Object Size -Descending | Select-Object -First 20 - 注意：同一个包（如
laravel/framework）可能有多个 hash 目录，代表不同版本；别只看 vendor 名，要合并统计同一 vendor/name 下的所有 hash 子目录才准
为什么 composer show 查不到缓存体积
composer show、composer show -i、composer show -s 全都不碰缓存目录，它们只读 composer.lock 和已安装的 vendor/。缓存是 Composer 的「下载中转站」，独立于项目结构存在，官方命令压根不提供索引或聚合接口。
常见误解是以为 composer why-not 或 composer depends 能反推缓存内容——不能。这些命令只分析依赖约束和锁文件，跟 ~/.composer/cache/files/ 完全无关。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 缓存本质是 key-value 存储：key 是 dist URL 的 SHA256 或 Git commit hash，value 是 zip/tar 包或解压副本
- 没有「包名 → 所有缓存版本」的映射表，也没有元数据描述每个 hash 对应哪个语义化版本
- 所以想确认
guzzlehttp/guzzle v7.8.1是否在缓存里？只能手动find ~/.composer/cache/files -name "*guzzle*" | xargs ls -ld，再结合文件名里的 hash 去查 packagist
哪些包最容易在缓存里“悄悄膨胀”
缓存体积大，往往不是因为代码多，而是包作者把非运行时必需的东西塞进了 dist 发布包里。高频踩坑点：
-
laravel/framework或symfony/symfony的完整源码包：含tests/、docs/、bin/、甚至整个.git/，单个 hash 目录轻松破 200 MB - 前端工具类 PHP 封装包（如
laravel-mix、spatie/laravel-medialibrary的 demo assets）：打包了 node_modules 或 build 输出物 - 带预编译二进制的包（如
spatie/browsershot、knplabs/knp-snappy）：缓存里存的是含 Chromium 或 wkhtmltopdf 的完整 zip，动辄 100–300 MB - 历史遗留的「全量 Git 发布」：某些包没设
"dist"，Composer 只能 clone 整个仓库，vcs/缓存里留着裸 Git 仓库（.git），一个就吃掉 300–800 MB + 大量 inode
清理前必须避开的三个坑
直接删 files/ 下某个 hash 目录看似精准，但容易引发后续命令失败：
- 别在
composer install或composer update运行时删缓存目录——会触发Corrupted cache file报错，因为 Composer 正在写入或校验锁文件 - 别只清
files/却忽略vcs/：Git 裸仓库单独占空间巨大，且composer clear-cache默认跳过它；必须手动rm -rf ~/.composer/cache/vcs/*（Linux/macOS）或rd /s /q "%APPDATA%\Composer\Cache\vcs"（Windows） - 权限问题最隐蔽：如果之前用
sudo composer install写过缓存，现在普通用户执行clear-cache会静默失败（无报错但不删），得先sudo chown -R $USER ~/.composer/cache
真正省事的方式不是狂删，而是定期跑 composer self-update——新版 Composer（2.9+）对缓存复用更聪明，比如共享相同 hash 的 dist 包，比反复清缓存更能稳住磁盘增长节奏。
