报错“Plugin X is not compatible with Composer 2”是插件未升级所致；应先运行 composer diagnose 锁定问题插件，再针对性更新、移除或降级，而非删除 vendor 或 composer.lock。
直接结论：报错“Plugin X is not compatible with Composer 2”不是 Composer 坏了，而是插件没升级；别删 vendor 或 composer.lock，先用 composer diagnose 锁定问题插件，再针对性处理。
怎么快速确认是不是插件导致的兼容问题
运行 composer diagnose，重点看输出末尾有没有类似 Plugin hirak/prestissimo is not compatible with Composer 2 的提示。没有这句，问题大概率不在插件本身；有这句，就基本可以锁定目标。它比 composer update 报错更早暴露问题，且不依赖是否已安装成功——哪怕插件只是声明了不兼容的 composer-plugin-api 版本，diagnose 就会报出来。
如果没看到插件相关提示，但执行 composer install 或 composer update 卡在加载阶段（比如停在 “Loading plugin…”），再补试：composer update --no-plugins --dry-run -v。这个组合能绕过插件加载，只做依赖解析；如果这时不报错，那 99% 是插件问题。
查插件到底支不支持 Composer 2
打开报错中提到的插件包（比如 hirak/prestissimo）的 Packagist 页面或 GitHub 仓库，搜 composer-plugin-api 字段：
- 如果值是
"^1.0"或压根没写，默认就是只支持 Composer 1 - 如果值是
"^2.0"或"^2.2.0"，说明作者已适配 - 如果 GitHub 最后一次提交早于 2022 年、issue 区大量 Composer 2 报错没人理、README 没提 v2 支持——基本可判定归档废弃
注意：别信 “兼容 1 和 2” 的模糊描述。Composer 插件机制在 v1 和 v2 中根本不同，activate() 方法签名、事件类路径、Capability 注册方式全变了。所谓“双版本声明”在 composer.json 里写成 "^1.0 || ^2.0"，会被 Composer 自身校验直接拒绝安装。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
临时救火和长期方案怎么选
短期能用但不推荐的做法：
- 全局插件出问题：用
composer global remove vendor/plugin-name移除 - 项目内插件出问题：用
composer remove vendor/plugin-name - 必须保插件？用
composer self-update --1降级到最新 1.x（目前是 1.10.22），但之后必须立刻跑composer install（不是update），否则composer.lock里残留的 2.x 字段会导致失败
真正可持续的做法：
- 优先
composer update vendor/plugin-name，有些作者悄悄发了兼容版但没改文档 - 插件已归档？fork 它，把
composer-plugin-api改成"^2.0"，再在项目composer.json的repositories里加你的 GitHub 地址，然后composer update plugin-name - 检查项目是否真需要这个插件——比如
hirak/prestissimo在 Composer 2 中已内置加速，装了反而冲突
容易被忽略的关键细节
很多问题卡在“看起来成功了，实际没生效”：
-
--dry-run不加载插件，所以它永远不报插件兼容错误；想验证真实加载行为，必须去掉这个参数 - 改完插件的
composer-plugin-api版本后，得实际跑一遍composer install并测试功能——API 版本兼容 ≠ 行为一致，比如Package::getNames()在 v2 已废弃，得换成getNamesWithStability() -
composer.lock文件本身也带版本语义：Composer 2 生成的 lock 文件含plugin-api-version字段，而 v1 生成的没有；混用会导致静默失效或解析异常，别指望靠删 lock 文件解决
