升级composer 2.x前须检查composer.json的require字段弃用语法，如开发依赖误入require；运行composer validate --strict验证；确保平台包在platform下；更新lock文件并适配插件v2 api；php≥7.2.5且启用ext-zip。
升级前必须检查 composer.json 的 require 字段是否含弃用语法
Composer 2.x 不再容忍某些宽松写法，最常见的是把开发依赖误写进主 require，比如 "phpunit/phpunit": "^9" 出现在 require 而非 require-dev。这类写法在 1.x 中能跑，2.x 会直接报错：Your requirements could not be resolved to an installable set of packages.
实操建议：
- 运行
composer validate --strict，它会标出所有不合规的字段和版本约束 - 重点检查
require、require-dev、conflict里是否混用了平台包（如ext-redis、lib-curl）——这些必须放在platform配置下 - 若项目用了自定义
repositories，确认它们返回的composer.json符合规范（特别是type和dist字段）
升级命令本身很简单，但 composer.lock 重生成逻辑变了
执行 composer self-update --2 就能升到 2.x，但真正影响日常开发的是 lock 文件行为：Composer 2.x 默认启用 lock 的哈希校验和更严格的依赖图解析，composer install 不再“自动修复”不一致的 lock。
实操建议：
- 升级后首次运行
composer install，如果 lock 文件是 1.x 生成的，会提示Warning: The lock file is not up to date with the latest changes in composer.json—— 这时别跳过，老老实实跑一次composer update --lock -
composer update默认不再更新次要版本（如从^2.1升到^2.2），除非显式加--with-all-dependencies - 若 CI 流程里用了
--no-interaction，确保没漏掉因 lock 变更触发的交互提示（虽然 2.x 已收敛很多，但个别插件仍可能输出 warning）
插件兼容性是最大雷区，尤其 hirak/prestissimo 和旧版 composer/installers
Composer 2.x 彻底移除了对 v1 插件 API 的支持，所有插件必须适配 v2 API。典型表现是升级后执行任何命令都卡住、报 Class 'Composer\Plugin\...' 找不到，或直接静默失败。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
实操建议：
- 先删掉
vendor/composer/autoload_plugins.php和vendor/composer/installed.json，再运行composer update让它重新发现插件 -
hirak/prestissimo已废弃，2.x 原生并行下载足够快，直接卸载：composer global remove hirak/prestissimo - 检查
composer show --plugins输出，确认每个插件的version标注了^2.0或更高；特别留意composer/installers必须 ≥2.0.0，否则drupal-module类型包安装路径错乱
PHP 版本和扩展依赖变严格，ext-zip 不再可选
Composer 2.x 要求 PHP ≥ 7.2.5，且强制依赖 ext-zip（用于解压 dist 包）。很多 Docker 环境或轻量容器默认不装这个扩展，升级后会立刻报错：ZipArchive class not found。
实操建议：
- 确认 PHP 版本：
php -v，低于 7.2.5 必须先升级 PHP - 检查扩展：
php -m | grep zip，没输出就补装（Debian/Ubuntu：apt-get install php-zip；Alpine：apk add php7-zip） - 若用
composer create-project初始化新项目，注意 2.x 默认走 dist 模式，没有ext-zip会回退到源码克隆，但部分私有仓库不支持源码模式，导致失败
最麻烦的不是升级动作本身，而是 lock 文件重生成后，某些包的自动加载规则（autoload）被 Composer 2.x 更严格地执行，导致原本能跑的代码突然 Class not found——这时候别急着 rollback，先看 composer dump-autoload -o 是否解决，再查那个类对应的包有没有在 autoload 字段里漏配 PSR-4 映射。
