composer本身不支持自动发现，laravel通过post-autoload-dump钩子执行php artisan package:discover命令实现，该命令读取installed.php、校验extra.laravel.providers、验证类可加载性后写入bootstrap/cache/packages.php。
Composer 本身不提供“服务发现”或“包自动发现”能力——这是 Laravel、Symfony 等框架基于 Composer 的元数据和钩子机制自行实现的功能，不是 Composer 内置行为。
为什么 composer install 后 Laravel 才能注册服务提供者
关键在 post-autoload-dump 钩子触发的 php artisan package:discover 命令。它不扫描文件系统，也不解析所有 composer.json，而是读取 vendor/composer/installed.php（Composer 2+）中已安装包的结构化记录，再逐个检查：
- 该包的
composer.json是否声明了extra.laravel.providers数组 - 数组中每个类名是否能被当前 autoloader 加载（即其命名空间必须已在该包自己的
autoload.psr-4或autoload.files中注册） - 该包是否真实出现在
installed.php的包列表里（本地path仓库未执行composer update就不会写入）
只有三者同时满足，才会把类名写入 bootstrap/cache/packages.php，供应用启动时加载。
extra.laravel.providers 字段的硬性校验条件
Laravel 的 package:discover 不会报错提示你哪条不满足，而是静默跳过。常见失效原因包括：
-
type字段不是library或laravel-package（例如是vcs或未设） - 服务提供者类路径未在该包自身的
autoload.psr-4中声明（父项目 autoload 不管用） - 包虽在
composer.json里写了require，但没运行composer install或composer update，导致installed.php无记录
验证方式：运行 composer show your-vendor/your-package，确认输出中有 extra 区块且字段完整；再手动执行 php artisan package:discover --force，观察是否抛出 Class not found。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
CI/CD 环境下 discovery 失效的典型原因
很多 CI 流水线为提速加了 --no-scripts，这会直接跳过 post-autoload-dump 钩子，导致 package:discover 根本不执行。结果就是 packages.php 是空的或过期的。
解决办法不是“多跑一遍 artisan”，而是在 CI 脚本中显式补上：
composer install --no-interaction --optimize-autoloader php artisan package:discover --ansi
注意：必须确保 composer install 成功完成后再执行 package:discover，否则 installed.php 可能尚未生成或不完整。
真正容易被忽略的是：discovery 不是 Composer 的职责，它依赖框架对 Composer 元数据的二次解释。一旦 installed.php 结构变更（如 Composer 1 → 2 升级）、或钩子脚本被禁用、或 autoload 配置未随包同步更新，整个链路就会静默中断——而错误日志里通常只显示“服务未注册”，不会指向 extra 字段缺失或类不可加载这种底层原因。
