Vendor目录越用越大是因为Composer默认安装全部依赖树而非按需加载。例如只用monolog却下载symfony/console等冗余包，导致体积膨胀、部署变慢、扫描风险增加；手动删除会破坏依赖链，应通过composer depends、show --tree定位并安全移除非必要包。
Vendor目录为啥越用越大
ThinkPHP默认把所有第三方库全扔进vendor目录，Composer install 时不管项目用不用，一股脑下全。比如你只用monolog/monolog记日志，却顺带下了symfony/consolesymfony/filesystempsr/log等一整套依赖树——这些未必被TP核心调用，但全堆在vendor里占空间、拖部署速度、增加扫描风险。
常见错误现象：git status显示vendor/下几百个文件变动；composer install耗时超2分钟；线上打包后vendor占150MB+；CI构建频繁因vendor体积超限失败。
删掉不用的包？别直接rm -rf
手动删vendor子目录看似快，实际极易破坏依赖链。Composer不认你手删的文件，下次composer update可能重装冲突版本，或导致Class not found运行时错误。
正确做法是反向追溯依赖来源：
立即学习“PHP免费学习笔记（深入）”；
- 运行
composer depends <package-name>查谁引用了某个包（如composer depends symfony/console） - 用
composer show --tree看当前项目完整依赖树，定位非必要分支 - 确认某包真没被任何地方加载：全局搜
use Symfony\Consolenew ConsoleApplication()等关键词，再检查config/app.phpextra配置项是否间接启用 - 移除前先加
--dry-run：例如composer remove symfony/console --dry-run，看会不会连带卸载TP核心组件
按需引入：用composer require --no-update + 精确限定版本
很多团队习惯composer require guzzlehttp/guzzle完事，结果拉下v7全量（含PSR-18、PSR-7、promises、streams等），而TP项目往往只用GuzzleHttp\Client发个HTTP请求。
更轻量的方案：
- 改用
composer require guzzlehttp/guzzle:7.5.1锁定小版本，避免自动升到v7.9+新增的冗余特性 - 若只需基础HTTP能力，考虑替换为
php-http/curl-client+php-http/httplug，体积减少60%以上 - 对日志、缓存等通用能力，优先用TP内置驱动（如
think-cache）而非引入doctrine/cache等重型包 - 所有
require操作后立即执行composer update --lock，防止composer.lock残留旧依赖
生产环境彻底剥离开发依赖
vendor臃肿常因开发期装的调试工具（如barryvdh/laravel-debugbarfilp/whoops）混入生产环境。TP本身不强制区分dev/prod，得靠Composer自己控制。
关键动作：
- 确认
composer.json中require-dev下的包确实只用于本地调试（如phpunit/phpunitmockery/mockery） - 上线部署必须用
composer install --no-dev --optimize-autoloader，否则require-dev包照常安装，且autoloader未生成静态映射，启动更慢 - 检查
autoload-dev字段是否误将测试类路径写进主加载器，导致生产环境也加载无用类 - CI脚本里加一行
du -sh vendor/* | sort -hr | head -10，定期监控TOP10大包，早发现异常增长
最麻烦的不是删包，而是搞清哪个use语句背后藏着三层依赖嵌套——得翻源码看它到底调了什么，不然删错一个psr/container，整个容器就起不来。
