Composer 1.x与2.x的主要区别及旧项目迁移指南

Composer 2.x 是底层重构升级，需检查依赖兼容性、插件适配性及锁文件行为变化；解析快2–5倍但会重算旧锁文件，内存降50%但部分插件报错，语义版本更严格，平台检查增强。

依赖解析快2–5倍，但旧锁文件可能触发重计算

Composer 2 用全新约束求解器替代了 1.x 的回溯算法，解析速度提升显著，尤其在含大量 dev 依赖或复杂版本约束（如 "^1.0 || ^2.0"）的项目中。但这也意味着：它不会“迁就”1.x 生成的 composer.lock 中模糊的版本记录。

• 首次运行 composer install 时，若锁文件由 1.x 生成，2.x 会重新解析整个依赖树，可能导致实际安装版本与之前不同（即使 composer.json 没变）
• 建议升级后立即执行 composer update --lock，让 2.x 生成符合其解析逻辑的新锁文件
• CI 流水线中若缓存了旧锁文件，需确保 composer install 前不带 --no-scripts，否则平台检查（如 ext-json 缺失）可能被跳过

内存占用降50%，但部分插件会报错“Class not found”

Composer 2 默认禁用部分 1.x 的反射式加载路径，且插件 API 已升级到 composer-plugin-api:^2.0。很多旧插件（尤其是未维护的私有插件）会直接抛出 Class 'Composer\Plugin\Capability\CommandProvider' 类不存在错误。

• 先运行 composer show --plugins 查看已启用插件及其版本
• 对每个插件，检查其 composer.json 中是否声明 "require": {"composer-plugin-api": "^2.0"}
• 若插件无更新，可临时降级 Composer：composer self-update --1（仅限紧急回滚），但不推荐长期使用
• 社区常用插件如 hirak/prestissimo 已废弃，2.x 原生支持并行下载，无需额外插件

语义版本匹配更严格，^ 和 ~ 行为有实质差异

Composer 2 对 semver 规范执行更精确，修复了 1.x 中多个边缘 case 的误判。例如："^1.9.0" 在 1.x 中可能意外匹配 1.10.0（因忽略补丁号位数），而 2.x 严格按 1.x.x 解析，只允许 1.9.x 范围内升级。

Pippit AI

CapCut推出的AI创意内容生成工具

下载

• 升级后若发现某包未按预期升级（如 monolog/monolog 卡在 2.8.0 不升 2.9.0），先检查其真实版本是否满足新规则
• 可用 composer prohibits vendor/package:version 定位阻塞源
• 不要强行加 --with-all-dependencies 绕过，这会掩盖真实冲突

平台检查和运行时验证增强，部署前就能发现环境问题

Composer 2 新增 composer check-platform-reqs 命令，并在 vendor/autoload.php 初始化时主动校验 PHP 版本、扩展是否存在。这意味着：以前上线后才报的 Call to undefined function json_encode()，现在 composer install 阶段就会中断。

• 在 Docker 构建中，务必在 composer install 后运行该命令，而非仅靠 php -m 粗略检查
• 若项目需兼容多 PHP 版本（如同时支持 8.1 和 8.2），应在 composer.json 中显式声明："config": {"platform": {"php": "8.1.0"}}，避免本地开发环境影响锁文件
• 注意：该检查不验证扩展的 *功能*（如 ext-curl 是否启用了 HTTP/2），只验证是否加载