应使用 composer why 定位包的引入路径，再用 composer remove 安全卸载；它自动清理声明、vendor目录、lock文件和autoload映射，但不处理代码中use语句、配置或服务注册等残留，需人工验证。
直接结论：用 composer why 查清包的引入路径，再结合 composer remove 安全删包——但别指望它自动识别“非核心”，Laravel 本身不定义哪些是“核心”，得靠你判断谁真在用、谁只是被顺带拉进来的幻影依赖。
怎么用 composer why 定位一个包到底是谁拉进来的
运行 composer why vendor/package-name，比如 composer why guzzlehttp/psr7，输出会列出所有直接或间接依赖它的包及其版本约束：
- 如果只看到
laravel/framework→ 说明它是 Laravel 自身需要的，删前得确认你没用到 HTTP 客户端相关功能（如Http::get()） - 如果看到
aws/aws-sdk-php和spatie/laravel-backup同时引用 → 说明它被多个工具链共享，删了可能让备份失败或 S3 上传报错 - 如果输出为空 → 这个包大概率是历史残留，没被任何依赖链引用，可以安全删
- 如果输出里带
(locked to x.y.z)→ 表示它被composer.lock固定住了，remove前得先确认是否要连带更新整棵树
删之前必须验证的三件事
别光看 why 输出就动手，以下检查漏一项都可能线上报 Class not found：
- 搜代码：用
grep -r 'use.*Guzzle' app/ config/或php -l扫所有 PHP 文件，确认没硬编码调用 - 查配置：打开
config/app.php、config/logging.php、app/Providers/下的服务提供者，看有没有注册该包的类或别名 - 跑测试：如果有单元测试或 Feature 测试，执行
vendor/bin/phpunit --filter Guzzle看是否挂掉；没测试？至少跑一遍php artisan tinker，手动 new 一下关键类试试
删的时候怎么避免锁文件和 autoload 错乱
composer remove 是唯一推荐方式，但它有行为边界：
- 加
--no-update：只改composer.json，不碰vendor/和composer.lock；适合批量删多个包后统一composer update --lock - 不加参数：默认会删
vendor/目录、更新lock、重建 autoload —— 但如果包被其他依赖硬 require，命令会中止并提示 “required by another package”，这是保护，不是失败 - 删完立刻执行
composer dump-autoload -o：强制刷新自动加载映射，否则旧类仍能 new 成功，掩盖问题 - 别用
composer install替代update：前者按lock精确还原，后者才真正重算依赖图；删包后必须用update来清理子依赖残留
为什么有些包删不干净，还留在 vendor/ 里
常见原因不是命令失效，而是依赖关系比你想的深：
-
psr/http-message被guzzlehttp/psr7和symfony/http-foundation同时 require → 删了 Guzzle，它还在，因为 Symfony 框架本身就要它 -
monolog/monolog被laravel/framework和phpunit/phpunit共同依赖 → 删掉 PHPUnit 后，Laravel 仍会把它拉进来 -
doctrine/annotations看似没人用，但laravel/framework的Route::middleware()注解解析依赖它 → 删了会导致路由注册失败
真正难的是判断“非核心”——Laravel 不提供白名单，composer why 只告诉你“谁拉的”，不告诉你“该不该留”。你得对照文档看功能是否启用，再决定动不动手。
