Composer版本更新后兼容性检查指南-composer-PHP中文网

确认插件是否兼容composer 2，需检查其composer.json中require或conflict字段是否声明"composer-plugin-api": "^2.0"（实际应为"^2.2.0"起），否则会静默失效或报错；可用composer diagnose定位不兼容插件。

composer版本更新后兼容性检查指南

Composer 升级到 2.x 后，插件不兼容是常态，不是配置错误；必须逐个验证插件是否声明支持 composer-plugin-api ≥2.0，否则会静默失效或报错。

怎么确认某个插件是否兼容 Composer 2

插件兼容性不看 GitHub star 数，只看它 composer.json 里有没有明确声明对 composer-plugin-api 的支持版本：

打开插件目录下的 composer.json，查找 "require" 或 "conflict" 字段中是否含 "composer-plugin-api": "^2.0"（或 "^2"、=2.0.0"）
若只有 "composer-plugin-api": "^1.0"，哪怕插件本身没报错，也可能跳过钩子逻辑（比如自动 dump-autoload）
运行 composer diagnose，它会在末尾提示 “Plugin X is not compatible with Composer 2” —— 但这个检查有时被缓存绕过，不能全信
最可靠方式：临时删掉 vendor/ 和 composer.lock，再执行 composer install -v，盯住输出里有没有 Plugin X: loading 或直接跳过该行

composer update --dry-run -v 报 “Conclusion: don’t install Y” 怎么快速定位源头

这个报错不是说 Y 包本身有问题，而是某条依赖链在强制锁死一个旧版 Y，导致新版无法装入。关键不是看报错行，而是翻到日志末尾的回溯路径：

Workflow Decomposer

工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。

下载

重点找形如 monolog/monolog 2.10.0 requires php ^7.2 || ^8.0 → laravel/framework 9.52.0 requires monolog/monolog ^2.4 → your-project requires php ^8.2 这类链条
如果链条里出现 requires (dev) phpunit/phpunit，立刻怀疑 require-dev 拖后腿；加 --no-dev 重试可快速验证
注意 config.platform.php 配置会覆盖真实 PHP 版本，导致 composer update --dry-run -v 模拟出错的环境；临时注释掉该段再试
别忽略间接依赖：用 composer depends -r vendor/package 查谁在锁死它，比手动翻 composer show --tree 更快

为什么 composer check-platform-reqs 显示 ext-zip 缺失，但 php -m 看得见

根本不是扩展没装，是 Composer 调用的 PHP CLI 二进制和你终端敲 php -m 的不是同一个：

运行 which php 和 composer config --global bin-dir，确认 Composer 启动时用的是哪个 php 路径
用完整路径复现：比如 /opt/homebrew/bin/php -m | grep zip，而不是只敲 php -m
macOS 上 Homebrew 安装的 PHP 常因 PATH 顺序被系统自带旧版覆盖；Windows 上注意 C:phpphp.exe 和 C: mppphpphp.exe 可能共存
check-platform-reqs 不读代码，只读 composer.json 的 require 字段，所以漏写 "ext-zip": "*" 就不会报——哪怕代码里真用了 ZipArchive

升级后 vendor/autoload.php 加载失败，别急着重装 Composer

90% 的情况不是 Composer 解析错了，而是 autoloader 自身被污染或未更新：

检查是否在入口文件里重复 require 'vendor/autoload.php' 了两次（常见于 Laravel 的 bootstrap/app.php + 自定义 index.php）
如果用了 classmap autoload 方式，升级后必须手动跑 composer dump-autoload，否则新类不会进映射表
PSR-4 和 classmap 同时映射同一命名空间（如 "App\": "app/" 和 "App\": ["app/", "src/"]）会导致类重复定义，报 Cannot declare class X, because the name is already in use
某些插件（尤其是旧版 hirak/prestissimo）会在 Composer 2 下干扰 autoloader 生成顺序，禁用插件后重试可快速验证

真正麻烦的不是报错本身，而是 Composer 2 的插件机制变化让很多“一直能用”的行为变成隐式失效——比如自动触发 dump-autoload 或修改 autoload_psr4.php 的时机。不要依赖“以前没问题”，每次升级后都该用 composer install -v 盯一遍插件加载日志。