生产环境中未被代码直接调用的Composer包是潜在故障源和安全风险，因--no-dev仅跳过dev依赖，无法清理误入require的调试包（如laravel-debugbar）、CI专用包或仅在测试中使用的包，它们仍会被autoload加载、占用内存并暴露攻击面。
生产环境里任何未被代码直接调用的 Composer 包，都是潜在故障源和安全风险点，不是“可能有用”，而是“必须确认无用才敢删”。
为什么 composer install --no-dev 不能代替手动清理
它只跳过 require-dev 下的包，但很多插件被错误地写进 require（比如本地调试用的 barryvdh/laravel-debugbar、开发时临时加的 phpunit/phpunit），--no-dev 完全不碰这些。更危险的是：某些包虽被 require，却只在测试或 CI 脚本里被调用，线上代码一行都没用到——它们照样会随 autoload 加载、占用内存、暴露攻击面。
- 典型误操作：把
symfony/var-dumper放进require，只为在 Tinker 里好看输出，结果它随所有请求加载 - 真实风险：一个未维护的
monolog/monolog旧版本，哪怕没被你主动调用，只要在vendor/里，就可能被其他包的反射或自动加载链触发漏洞 - 性能影响：每个额外包都会增加
composer dump-autoload -o生成的类映射体积，拖慢容器冷启动和 FPM 进程初始化
如何定位真正无用的依赖
核心逻辑是「代码中没出现、运行时不加载、配置里没引用」——三者缺一不可。别信 README 或作者说的「轻量」，只信你自己的 grep 和日志。
- 先跑
grep -r "use.*ClassName" app/ bootstrap/ config/ --include="*.php" | cut -d' ' -f2 | sort -u，提取所有显式引用的类名 - 再用
php -d display_errors=0 -d log_errors=0 -d error_log=/dev/null index.php 2>/dev/null || echo "exit code: $?"模拟一次最小请求，配合strace -e trace=openat,open -f php index.php 2>&1 | grep vendor看实际打开哪些vendor/文件 - 检查
config/app.php的providers和aliases，还有phpunit.xml、.env里是否隐含启用某包（比如DEBUG=true激活了某个调试中间件）
删之前必须验证的三个动作
删错一个包可能导致整个应用 500，尤其 Laravel 项目里有些包被服务提供者深度耦合。不能只靠 composer remove 就完事。
- 执行
composer remove vendor/package-name --no-update（加--no-update防止自动重装依赖树） - 手动删掉
vendor/vendor-name/package-name目录，并清空bootstrap/cache/*.php - 启动 PHP 内置服务器：
php -S localhost:8000 -t public router.php，逐个访问核心路由，同时tail -f storage/logs/laravel.log监控异常；重点测表单提交、文件上传、队列任务等易触发 autoload 的路径
上线前最后一步：锁定并审计
清理后不立刻 push composer.lock，先用工具交叉验证。很多团队删完以为干净了，结果 CI 流水线里因缓存或不同 PHP 版本又拉下旧包。
- 跑
composer show --direct对比清理前后列表，确认目标包已消失 - 用
composer outdated --direct检查剩余包是否都还在维护周期内（比如guzzlehttp/guzzle:^7.0已 EOL） - 在生产镜像构建阶段加入
composer validate --strict和composer licenses --format=json | jq 'length'，确保没有意外引入闭源或高危许可证包
真正的纯粹不是删得越多越好，而是每个留在 vendor/ 里的包，你都能在 10 秒内说出它被哪行代码调用、解决什么具体问题、以及替换它的成本是多少。否则，它就是待清理项。
