Composer 没有内置 bump 命令，因其设计哲学强调显式声明依赖与人工确认兼容性，仅提供 require、update 等基础操作；社区需求需借助第三方工具或手动组合命令实现。
Composer 没有内置的 bump 命令，直接运行 composer bump 会报错：「Command "bump" is not defined.」官方 composer CLI 不支持一键提升依赖版本号。
为什么 composer bump 不存在？
Composer 的设计哲学是显式声明依赖，而非自动修改 composer.json。版本升级需人工确认兼容性，因此核心命令只提供 require、update、install 等基础操作。所谓“bump”属于社区衍生需求，必须借助第三方工具或手动组合命令实现。
用 composer require 手动 bump 单个包
这是最可控、最常用的方式，适用于明确知道目标版本（或约束）的场景：
- 升级到固定版本：
composer require monolog/monolog:^2.10.0（会重写composer.json中该包的约束，并执行安装） - 仅更新约束不安装：
composer require monolog/monolog:^2.10.0 --no-update - 降级或切回旧版也适用，例如：
composer require symfony/console:5.4.*
⚠️ 注意：require 会触发依赖解析，若新版本与现有其他依赖冲突，命令会失败并提示 conflict 信息，不能强行覆盖。
用 composer update 批量 bump 兼容版本
当想把所有满足当前约束的包升到最新兼容版（如从 ^7.4 升到 ^7.4.12），用 update 更合适：
- 仅更新某几个包：
composer update monolog/monolog guzzlehttp/guzzle - 跳过平台检查（如 PHP 版本不匹配但你确定可行）：
composer update --ignore-platform-req=php - 生成更精确的锁文件（推荐 CI 中使用）：
composer update --lock
⚠️ 关键区别：update 不修改 composer.json，只更新 composer.lock 和 vendor；而 require 会改 composer.json 并更新 lock。
用社区工具 roave/composer-dependency-analyser 或 composer-unused 辅助判断是否可 bump
真正卡住 bump 的往往不是命令，而是不确定“升了会不会坏”。这时需要静态分析辅助：
-
roave/backward-compatibility-check可比对两个版本间 BC break（适合发布前验证） -
composer show --outdated是最轻量的起点，列出所有可升级项及最新兼容版本 - 若项目用了大量 dev-master 或
@dev，先运行composer update --with-dependencies再检查，避免漏掉间接依赖的变动
没有银弹工具能全自动安全 bump —— 版本号背后是语义化含义、API 变更、破坏性改动。哪怕 ^ 约束，也要看 CHANGELOG，尤其 major 版本跨越时。
