Composer无需镜像插件，直接配置镜像源即可：全局用composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，项目级用composer config repo.packagist composer https://mirrors.tuna.tsinghua.edu.cn/composer/，验证执行composer config repo.packagist应返回对应URL。
Composer 没有“镜像插件”这个东西——你真正需要的是配置镜像源，或者安装能自动管理镜像的 Composer 插件（极少数），但绝大多数场景下，直接改 config 就够了。
composer config repo.packagist 是最直接有效的镜像设置方式
国内访问 packagist.org 极慢甚至超时，根本原因不是缺插件，而是 DNS、路由或证书问题。Composer 本身支持运行时切换仓库地址，无需任何插件介入。
- 全局生效（推荐）：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 仅当前项目生效：
composer config repo.packagist composer https://mirrors.tuna.tsinghua.edu.cn/composer/ - 验证是否生效：运行
composer config repo.packagist，输出应为镜像 URL，不是packagist.org - 阿里云镜像已强制 HTTPS，若提示
SSL operation failed，说明本地 OpenSSL 未启用或 CA 路径异常，不是镜像配置问题
所谓“镜像插件”通常指自动切换源的第三方包，但基本已被淘汰
过去有类似 hirak/prestissimo（并行下载）或自定义 RepositoryManager 的插件试图动态代理请求，但 Composer 2.2+ 内置了更稳定、更安全的镜像机制，且插件需显式允许（allow-plugins），反而增加部署复杂度。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 搜索
composer mirror plugin几乎找不到维护活跃的包；主流镜像站（阿里、清华）也不提供插件形式接入 - 真有企业内网需求（如对接 GitLab 私有源 + fallback 到阿里镜像），应通过
repositories字段手动声明复合源，而非依赖插件 - 若强行 require 一个声称“自动切镜像”的包，先检查它是否声明
"type": "composer-plugin"和PluginInterface实现——大概率只是普通工具包，require 后不会自动生效
执行 install/update 前必须确认 allow-plugins 配置不阻断合法插件
即使你真装了一个镜像管理插件（比如内部开发的 corp/mirror-manager），Composer 2.2+ 默认会拒绝加载，除非你在项目根目录 composer.json 中明确放行。
- 检查是否被全局禁用：
composer config -g allow-plugins，若输出false，需重设为null或具体白名单 - 项目级优先级最高：在
composer.json顶层加"extra": {"allow-plugins": {"corp/mirror-manager": true}}，大小写敏感，不支持通配符 -
"config": {"disable-plugins": true}会彻底关闭所有插件，哪怕 extra 允许也无效，务必确保该字段不存在或值为false - 插件类构造函数若抛异常（如读取配置失败），Composer 会静默跳过，不报错也不激活——建议插件入口加
$io->write('[MirrorPlugin] loaded');辅助验证
镜像的本质是 HTTP 仓库地址替换，不是功能扩展。别被“插件”二字带偏——99% 的场景，composer config repo.packagist 一行命令就解决，多出来的插件只会增加兼容性风险和 CI 失败概率。
