自动发现功能不依赖镜像源，但镜像失效会导致发现失败：插件在post_autoload_dump事件中读取vendor/composer/installed.json里的extra字段触发发现逻辑，而该文件内容取决于镜像是否完整同步并返回含extra的元数据；镜像超时、404、缺字段或配置错误（如url无尾部/、type非composer）均会导致autoload.php生成失败或extra为空，从而使自动发现静默失效。
自动发现功能不依赖镜像源，但镜像失效会导致发现失败
Composer 的“自动发现”（如 Laravel 的 service provider 自动注册、Symfony bundles 自动加载）完全由插件在 POST_AUTOLOAD_DUMP 事件中读取目标包的 composer.json 中 extra 字段触发，和镜像源无关。但前提是：目标包的 composer.json 能被正确下载并解析。
如果镜像源返回空 JSON、超时或缺失元数据（比如 /p2/vendor/package.json 返回 404 或空响应），Composer 就无法读取该包的 extra.laravel.providers 等字段——不是插件没运行，而是根本没拿到配置。
- 常见现象：
composer install成功，但 Laravelphp artisan tinker报Class not found，且vendor/composer/installed.json里对应包的extra字段为空或缺失 - 验证方式：手动请求镜像地址，例如
curl -fsSL https://mirrors.aliyun.com/composer/p2/laravel/framework.json | jq '.packages."laravel/framework"[0].extra'，看是否返回有效 JSON - 镜像同步延迟超过 1 小时，新发布的包带
extra声明，但镜像未同步 → 插件扫描不到，自动发现静默失效
镜像配置错误会中断 vendor/autoload.php 生成，导致发现逻辑不执行
POST_AUTOLOAD_DUMP 事件只在 composer dump-autoload 或 install/update 成功生成 vendor/autoload.php 后才触发。而 autoload 文件生成失败，往往就卡在镜像环节。
典型原因包括：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
composer.json中repositories里镜像 URL 缺尾部/，导致 Composer 拼出错误路径如https://mirrors.ustc.edu.cn/composerp2/...（漏了斜杠 → 拼接错误） - 镜像声明为
"type": "packagist"而非"type": "composer"，Composer 会忽略该源，回退到官方源，但中文环境下常因 DNS 或 TLS 问题卡住，最终autoload.php不生成 -
composer config -g repo.packagist输出不是完整 JSON（如只显示 URL 字符串），说明配置损坏，全局镜像未生效，项目又没配repositories→ 所有包都从packagist.org拉，容易超时失败
多镜像 failover 下，自动发现行为不可预测
Composer 原生不支持 failover，只是按 repositories 数组顺序逐个尝试。这对自动发现很危险：不同镜像同步状态不一致，可能导致同一包在 A 镜像里有 extra 字段，在 B 镜像里没有（或字段为空）。
结果是：两次 composer update 在相同环境可能生成不同的 vendor/composer/installed.json，进而导致插件读到的 extra 内容不同，自动注册的服务提供者时有时无。
- 最稳妥做法：禁用所有备用镜像，只留一个高可用源（如阿里云），并在 CI 中用
composer show -a vendor/package | head -5校验关键包的extra字段是否存在 - 避免在
repositories里混写多个中文镜像，尤其不要把已知同步慢的源（如某些小众镜像）放在靠前位置 - 若必须多源，应在部署脚本中加校验：
php -r '$j = json_decode(file_get_contents("vendor/composer/installed.json"), true); foreach ($j as $p) { if ($p["name"] === "laravel/framework" && empty($p["extra"]["laravel"]["providers"])) die("auto-discovery broken\n"); }'
插件本身对镜像无感知，但依赖的包元数据必须完整
插件代码里调用 $package->getExtra() 时，拿到的数据来自 vendor/composer/installed.json，而这个文件的内容，取决于 Composer 当前从哪个镜像成功下载并解析了该包的 composer.json。
也就是说：插件不关心你用的是哪个镜像，但它极度依赖镜像返回的数据质量。一个看似正常的镜像，可能只同步了 dist 包 ZIP，却漏掉了 p2/ 元数据接口，或者返回的 JSON 缺少 extra 字段（某些镜像站会 strip 掉非标准字段）。
- 排查优先级：先确认
vendor/composer/installed.json里目标包的extra是否存在且结构正确，再查插件逻辑 - 不要在插件中做镜像适配逻辑——Composer 不暴露当前使用的是哪个镜像，也无法在运行时切换
- 本地开发时可临时用
composer config --no-plugins关掉插件，再composer install看installed.json是否正常，快速区分是镜像问题还是插件问题
installed.json 的链路。
