Laravel项目中冗余包主要指require-dev里的开发依赖（如laravel/tinker、facade/ignition）及未使用的生产包（如laravel/sanctum），需通过--no-dev --optimize-autoloader部署、移除无引用服务提供者、检查隐性依赖并全面验证功能。
哪些包在 Laravel 项目里大概率是冗余的
新装的 Laravel 默认带了不少开发期才用得上的扩展包，比如 laravel/tinker、facade/ignition、phpunit/phpunit，这些在生产环境完全不需要加载，却会拖慢 composer install 和自动加载性能。尤其当部署到容器或低配服务器时，自动加载器生成的 vendor/autoload.php 文件体积变大，会直接影响请求响应速度。
判断依据很简单：看 require-dev 里的包是否被线上代码实际调用过。例如 orchestra/testbench 只用于包开发，mockery/mockery 仅测试用——上线前必须移除。
- 运行
composer show --dev列出所有开发依赖 - 检查
config/app.php的providers和aliases，确认没有引用对应包的服务提供者或门面 - 搜索项目代码（含
routes/、app/、tests/）中是否出现该包的类名或 Facade，比如TinkerServiceProvider或IgnitionServiceProvider
如何安全地移除 dev-only 包并避免 autoload 膨胀
直接删 require-dev 项还不够。Composer 默认会为所有包（包括 dev）生成类映射，除非你明确告诉它“只 autoload production 依赖”。关键参数是 --no-dev 和 --optimize-autoloader（简写 -o）。
部署脚本里务必用这组组合：
composer install --no-dev --optimize-autoloader
注意：--optimize-autoloader 会让 Composer 把 PSR-4/PSR-0 映射预生成进 vendor/composer/autoload_classmap.php，跳过运行时文件扫描；而 --no-dev 不仅跳过安装，还会让 autoloader 完全忽略 require-dev 中定义的命名空间。
- 本地开发仍可保留
require-dev，不影响日常调试 - CI/CD 流水线或部署命令中漏掉
--no-dev，会导致facade/ignition这类包被加载，触发未预期的异常（比如试图注册已禁用的 Service Provider） - 若用了
classmap方式加载某些自定义类，记得在composer.json的"autoload": {"classmap": [...]}里只保留生产必需路径
Laravel 自带但可按需关闭的“重型”扩展包
有些包虽在 require 里，但功能高度垂直，比如 laravel/sanctum（API 认证）、laravel/scout（全文搜索）、laravel/horizon（队列监控）。如果你没在代码里调用它们，不光是浪费磁盘空间，还可能因自动发现机制悄悄注册中间件或监听器。
典型表现：
- HTTP 请求耗时莫名增加 10–20ms，查出是
SanctumServiceProvider在每次请求中检查 token -
php artisan config:cache失败，报错Class "Laravel\Scout\Searchable" not found，说明配置里残留了 Scout 相关配置但包已卸载 - 队列 worker 启动变慢，因为
horizon的HorizonServiceProvider注册了大量事件监听器
操作建议：
- 先注释掉
config/app.php中对应服务提供者的类名（如Laravel\Sanctum\SanctumServiceProvider::class） - 运行
php artisan config:clear防止缓存干扰 - 确认无报错后，再执行
composer remove laravel/sanctum - 最后全局搜索项目，删掉所有
use Laravel\Sanctum\*、Sanctum::、->withAccessToken()等调用
精简后要注意的隐性依赖和兼容陷阱
有些包看似独立，实则被 Laravel 核心间接依赖。比如 guzzlehttp/guzzle 是 laravel/framework 的子依赖（用于 HTTP Client），不能随便 remove；但 aws/aws-sdk-php 若没用 S3 存储驱动，就可以安全移除。
更隐蔽的是“软依赖”：某些包没写在 composer.json 里，但通过 class_exists() 或 interface_exists() 动态检测是否存在，比如部分日志驱动或缓存适配器。强行删除可能导致 Call to undefined function 或静默降级。
- 用
composer depends查谁依赖它，例如composer depends guzzlehttp/guzzle - 检查
vendor/laravel/framework/src/Illuminate/Foundation/Providers/下各 Provider 的register()方法，看是否条件加载了某扩展 - 上线前务必跑一次
php artisan tinker --execute="echo 'ok';"，验证基础容器能正常启动
真正难的不是删包，而是确认删完之后，所有请求路径、队列任务、Artisan 命令、甚至 Horizon 的 Web UI（如果还在用）都还能走通。这点很容易被忽略。
