Laravel自动发现依赖包的composer.json中extra.laravel.providers数组声明，启动时读取bootstrap/cache/packages.php注册服务提供者；未正确配置则不会被识别。
自动发现不是 Laravel 框架“主动扫描”你写的类，而是 Composer 安装包时读取 composer.json 里的 extra.laravel.providers 字段，再由 Laravel 启动时批量注册——没写对字段、路径或类名，它根本不会“看见”你的服务提供者。
怎么确认包是否被 Laravel 自动发现了
别猜，直接看缓存文件。Laravel 把所有被发现的包信息汇总到 bootstrap/cache/packages.php，这是最权威的证据。
- 删掉
bootstrap/cache/packages.php（别怕，下次启动会重建） - 运行
composer update --lock（哪怕没更新任何包，也会强制重生成 manifest） - 打开刚生成的
bootstrap/cache/packages.php，搜索你的包名，比如your-vendor/your-package - 如果找到类似
'providers' => ['YourVendorYourPackageServiceProvider']的条目，说明发现成功；如果只有空数组或压根没出现，就是配置没生效
为什么 php artisan package:discover 没用或没输出
这个命令只是触发一次重新扫描，但它不解决根本问题。常见失效原因：
-
composer.json里漏了extra.laravel.providers字段，或者写成了extra.laravel.provider（少个 s） - 数组值是字符串而非完整命名空间，比如写了
"ServiceProvider"而不是"YourVendorYourPackageServiceProvider" - 类文件路径和 PSR-4 自动加载不匹配：比如
autoload.psr-4声明为"YourVendor\YourPackage\" : "src/"，但实际类放在src/Providers/ServiceProvider.php，而命名空间却是YourVendorYourPackageServiceProvider—— 这会导致类找不到，即使发现成功，启动时也报Class not found - 包类型不是
library或laravel-package，某些旧版 Composer 会跳过非标准 type 的包
自动发现 ≠ 自动发布资源
这是最容易踩的坑：发现成功后，config/、migrations/、views/ 这些文件依然不会自动复制过去。
- 服务提供者中必须显式调用
$this->publishes()，且第一个参数是源路径 → 目标路径的关联数组 - 运行
php artisan vendor:publish --provider="YourVendorYourPackageServiceProvider"才能导出资源 - Laravel 9+ 对
publishes()的源路径做存在性校验：如果__DIR__.'/../config/package.php'这个文件不存在，命令会静默跳过，不报错也不提示 - 如果你在
composer.json里加了"dont-discover": ["your-vendor/your-package"]，那整个包都不会被扫描，连服务提供者注册都跳过
开发阶段怎么快速验证服务提供者逻辑
别等跑完整个请求周期，用 tinker 直接测容器行为最省事。
- 先确保类能被自动加载：
composer dump-autoload（改完composer.json或新增类后必做） - 运行
php artisan tinker，然后输入：app('YourVendorYourPackageSomeService')或app()->make('YourVendorYourPackageServiceProvider') - 如果报
Target [xxx] is not instantiable，检查构造函数依赖是否都可解析；如果报Class not found，回溯 PSR-4 和文件路径 - 注意：服务提供者本身不一定要绑定到容器，但它的
register()方法里绑定的服务，必须能在tinker中通过app()取到
自动发现机制本身很轻量，但它极度依赖配置的精确性——一个斜杠、一个字母大小写、一个缺失的 use 语句，都可能导致整条链路中断。调试时优先查 packages.php 和 composer show 输出，而不是重写服务提供者代码。
