应使用 composer remove 清理显式依赖或重建 vendor 目录剔除孤儿包；因直接删 vendor/ 或改 composer.json 会破坏 autoload 和锁文件一致性，而真正提升性能的关键是减少 autoload 映射广度与深度。
移除无用依赖能显著提升 Composer 项目性能，但直接删 vendor/ 或手动改 composer.json 不仅无效，还会破坏 autoload 和锁文件一致性——真正起效的操作只有两个：用 composer remove 清理显式依赖，或重建 vendor/ 目录来剔除所有“孤儿包”。
为什么删包能提升性能？关键在 autoload 和类扫描
Composer 的自动加载器（尤其是未优化的 PSR-4 映射）会在每次请求时遍历大量路径和命名空间前缀。哪怕一个包只被声明但完全没用，它的 autoload 配置仍会写入 vendor/composer/autoload_psr4.php，PHP 启动时就得加载并检查这些映射。更隐蔽的是：某些包带大量 stub 文件、注解扫描入口或配置钩子（如 Doctrine、PHPStan），即使没调用，也会拖慢 composer dump-autoload -o 和框架启动速度。
- 运行
composer show --tree查看依赖深度，树越深、autoload 映射越多，冷启动越慢 - 执行
composer dump-autoload -v（加-v看详细日志），观察是否在扫描已删除包的目录 - 特别注意
symfony/polyfill-*、psr/*类包：它们体积小但数量多，叠加后 autoload 文件可增长数倍
composer remove 什么时候有效？又为什么经常“删不动”？
composer remove 只清理你明确写在 composer.json 的 require 或 require-dev 里的包，并自动删掉它独占的子依赖。但它不会碰“被其他包间接拉进来的孤儿包”，也不会识别代码里是否还残留调用。
- 删之前先确认包名完整且大小写一致：
composer show | grep -i guzzle，别输成guzzlehttp/guzzle却敲了guzzle/guzzle - 如果报错
Package "xxx" is not required in your composer.json，说明它没被显式声明，而是某个require-dev包带进来的，得先查composer depends xxx - 删
phpunit/phpunit时必须加--dev：不加默认只查require，必然失败 - 删完立刻运行
composer dump-autoload -o，否则旧映射还在内存里，Class not found错误照常报
怎么发现并清掉真正的“孤儿依赖”？
所谓孤儿依赖，是指既没出现在 composer.json 的 require/require-dev 中，也没被任何已安装包声明为 require 的包。它们常年躺在 vendor/ 里，autoload 白扫、CI 白检、安全扫描白报漏洞。
- 最准的方法：删掉整个
vendor/和composer.lock，再跑composer install—— 这会严格按composer.json重装，所有孤儿包自动消失 - 轻量筛查：用
composer-unused插件，它扫描src/和tests/下所有use语句，列出没被引用的包（注意：动态加载如class_exists('Foo\Bar')默认不识别） - 别信
composer show --tree的叶子节点：某psr/log看似是叶子，但可能被框架核心组件悄悄 require，删了会直接Fatal error
删完之后，最容易被忽略的三处残留
很多团队删包后线上报错，不是因为没删干净，而是忘了这几处硬编码引用：
- 全局搜索类名：比如删了
guzzlehttp/guzzle，就跑grep -r "GuzzleHttp\" . --include="*.php"（反斜杠要转义） - Laravel 用户重点查
config/app.php里的providers和aliases数组，删包后这里不清理，启动就Class does not exist - 运行
php artisan config:clear和php artisan cache:clear，否则旧服务提供者注册逻辑还在缓存里
真正影响性能的从来不是 vendor 目录大小，而是 autoload 映射的广度和深度。删包只是手段，验证是否还有残留类加载路径，才是调优闭环里最后也是最关键的一步。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
