升级到 Composer 2 可提升性能并获得新特性支持，因 Composer 1 已停止维护，升级至关重要。需先验证项目兼容性，运行 composer validate、diagnose 和 update --dry-run 检查格式、环境及依赖冲突，注意“could not parse version”或“conflict”提示，必要时替换老旧包。避免直接在生产环境操作，先在本地或 CI 环境确认当前版本 composer --version，执行 composer self-update 升级至 v2，调试时可降级回 v1。升级后依赖解析引擎变更，可能影响插件或自定义脚本行为。建议提交现有 composer.lock 以便回滚，再运行 composer update 生成新版锁文件，检查 vendor/ 目录变化，尤其是大版本升级的依赖。全面执行功能、集成和自动化测试，确保 post-install-cmd 等钩子脚本正常运行。预发布环境验证无误后再部署生产，上线后监控应用启动错误、性能表现及 CI/CD 中 composer install 是否成功。若遇问题可临时回退至 Composer 1，修复依赖后再升级。只要依赖清晰、测试充分，过程通常平滑，但需重点关注第三方插件兼容性和脚本行为变化。
升级到 Composer 2 能带来性能提升和新特性支持，但需确保项目兼容性。Composer 1 已于 2022 年停止维护，因此升级是必要的。关键在于逐步验证依赖、锁定版本并测试变更影响。
检查项目依赖是否兼容 Composer 2
Composer 2 对依赖解析更严格，部分旧包可能不兼容。先运行以下命令查看潜在问题：
- composer validate：确认 composer.json 格式正确
- composer diagnose：检查环境配置问题
- composer update --dry-run：模拟更新，观察依赖变动
重点关注提示“could not parse version”或“conflict”的信息。某些老旧包可能需要手动替换为维护中的替代方案。
备份并切换 Composer 版本
不要直接在生产环境操作。本地或 CI 环境中执行：
立即学习“PHP免费学习笔记（深入）”；
- 确认当前版本：composer --version
- 全局升级 Composer：composer self-update（默认会升级到最新稳定版，即 v2+）
- 若需降级调试，可用 composer self-update --1
升级后，Composer 会自动使用新的依赖解析引擎。注意某些插件或自定义脚本可能依赖旧行为，需逐一验证。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
重新生成锁文件并测试
Composer 2 可能生成不同的 composer.lock。建议：
- 提交当前 composer.lock 到版本控制，便于回滚
- 运行 composer update 生成新版 lock 文件
- 检查 vendor/ 目录变更，尤其是重大版本升级的包
- 执行项目全部测试用例，包括功能、集成和自动化测试
如使用了脚本钩子（如 post-install-cmd），确认它们仍按预期执行。
部署与监控
在预发布环境验证无误后，再推送到生产。上线后关注：
- 应用启动是否报错（特别是类未找到）
- 性能变化（Composer 2 通常更快）
- CI/CD 流程是否正常运行 composer install
如有问题，可临时回退到 Composer 1，修复依赖后再试。
基本上就这些。只要依赖清晰、测试充分，升级过程是平滑的。不复杂但容易忽略的是第三方插件兼容性和钩子脚本的行为变化。
