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运行时错误。

正确做法是反向追溯依赖来源：

• 运行composer depends <package-name></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，整个容器就起不来。

php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！