“composer bump”命令不存在，composer官方从未实现该命令；它常被误认为存在是因项目scripts定义、第三方插件或ci封装所致；真正需依赖升级时应使用composer require或update。
“composer bump” 命令根本不存在，直接运行必报错 Command "bump" is not defined —— 这不是你环境没配好，而是 Composer 官方压根没这个命令。
为什么 composer bump 一定失败
截至 2026 年 4 月，Composer 2.x 所有稳定版本均未将 bump 纳入核心命令。错误信息是确定性的：它不依赖 PHP 版本、不看 composer.json 结构、也不受全局插件干扰——就是没实现。
常见误以为它存在的原因：
- 项目
composer.json的scripts里定义了"bump": "php scripts/bump.php"这类别名 - 团队全局装了
vinkla/composer-bump或symplify/composer-bump，但它们只改自己项目的version字段，和依赖约束无关 - CI 脚本里用
make bump封装了一组操作，被当成 Composer 原生命令传播
想把依赖约束更新为已安装的精确版本（锁死）
这其实是“固化当前实际使用版本”，比如把 "monolog/monolog": "^2.9" 改成 "monolog/monolog": "2.10.0"。官方没有一键命令，但必须靠真实安装状态驱动：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 查已安装版本：
composer show monolog/monolog（输出类似versions : * 2.10.0） - 只改约束不安装：
composer require monolog/monolog:2.10.0 --no-update - 批量处理需脚本：读
composer.lock中的packages数组，对每个包生成composer require name:version --no-update命令流 - 执行前务必
git add composer.json && git commit -m "pin deps to lock versions"，否则后续composer update不会再升
想升级依赖的版本约束（如 ^2.9 → ^3.0）
这才是日常开发中最常需要的“bump”含义。唯一官方支持、可预测、可审计的方式是 composer require：
- 放宽约束并安装：
composer require monolog/monolog:^3.0 - 只改约束不安装：
composer require monolog/monolog:^3.0 --no-update - 手动编辑
composer.json后，用composer update monolog/monolog触发安装（更可控，适合多包协同调整） - 升级前先运行
composer outdated monolog/monolog，确认目标版本是否存在、是否兼容
注意：composer update 不修改 composer.json，它只按现有约束拉最新匹配版；而 require 是唯一能安全覆盖约束的原生命令。
第三方插件能帮你做什么，不能帮你做什么
像 vinkla/composer-bump 或 symplify/composer-bump 这类工具，只处理 composer.json 顶层的 "version" 字段（即你这个包自身的发布版本），例如从 "1.2.3" 升到 "1.3.0"，并自动打 Git tag。
它们完全不碰 require 里的依赖项，也不读 composer.lock，更不会判断 ^2.9 和 ^3.0 之间是否有 BC break。真正难的从来不是改那行文本，而是决定该 bump 到哪——得看 CHANGELOG、测试覆盖率、你代码里实际调用的 API 范围。
