composer无内置查包大小命令，需用du（linux/macos）或powershell（windows）统计vendor目录磁盘占用，或安装clue/composer-show-size插件全局运行composer show-size以过滤非运行时文件并统计核心路径体积。
如何用 Composer 插件快速查看已安装包的磁盘占用？
直接看 vendor/ 目录大小不准确——很多包含测试、文档、源码注释，而实际运行只用其中一小部分。真正有效的办法是用 composer-unused 或更轻量的 composer-show-size 插件。
- 推荐安装：
composer global require clue/composer-show-size（注意：不是项目内安装，是全局） - 运行：
composer show-size，它会递归统计每个包下src/、lib/、bin/等核心路径的实际字节数，过滤掉tests/、docs/、.git/ - 若报错
Class 'Clue\ComposerShowSize\Plugin' not found，说明 Composer 版本太高（v2.5+），需改用composer install --no-dev && du -sh vendor/* | sort -hr | head -20临时替代
为什么 composer require 后 vendor 体积暴增？关键看依赖树里的“隐性大包”
不是所有大包都显眼。有些包本身不大，但拉进来的 symfony/console 或 guzzlehttp/guzzle 带着完整组件栈，或引入了 phpunit/phpunit（即使你没装 dev 依赖，某些包的 require-dev 会被错误继承）。
- 查真实依赖链：
composer depends --tree vendor/package-name，重点看有没有非预期的高权重包（如laravel/framework被一个日志工具间接依赖） - 检查
composer.lock中该包的dist/size字段（若有），它是 packagist 下载时的压缩包大小，可初步判断是否臃肿 - 警惕带
dev-前缀的包版本——它们常含未清理的调试文件、冗余 demo 脚本，体积可能是稳定版的 3–5 倍
镜像同步慢 + vendor 体积异常大？大概率是镜像源没做 clean up
国内某些 Composer 镜像（如早期阿里云、腾讯云镜像）曾长期缓存旧版 tarball，且未定期清理重复归档。结果就是 composer update 拉下来的包，解压后比官方源多出几十 MB。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 验证方式：对比同一包在不同源的
dist/url，比如访问https://packagist.org/p2/monolog/monolog.json和对应镜像地址，看dist/sha256是否一致 - 临时绕过：加
--repository=https://repo.packagist.org强制走官方源更新单个包 - 长期方案：改用支持
clean-dist-cache的镜像，例如https://packagist.phpcomposer.com（已停）→ 现在推荐https://mirrors.aliyun.com/composer/并确认其last_updated在 7 天内
删不掉的“幽灵体积”：autoload 生成器和 classmap 缓存残留
有时 composer remove xxx 后 vendor/ 变小了，但 composer dump-autoload 再跑一次，又多出几十 MB——问题出在 vendor/composer/autoload_classmap.php 或 vendor/composer/autoload_psr4.php 里还存着已删除包的路径映射，导致 Composer 自动加载器仍尝试扫描那些目录。
- 手动清理：
rm -f vendor/composer/autoload_*.php && composer dump-autoload - 更彻底：
composer clear-cache && rm -rf vendor/ && composer install（别省这一步，尤其 CI 环境） - 注意
composer.json中的autoload/classmap若指向了整个src/，而该目录下混着第三方代码，也会被一并扫入 classmap，体积虚高
实际排查时，体积问题往往卡在“镜像缓存 + autoload 残留 + 隐性依赖”三者的叠加。单独看任一环节都正常，合起来就失控。动手前先 ls -la vendor/ | head -10 扫一眼最大目录，比盲目分析 lock 文件快得多。
