Composer 2.5+ 才支持 bump 命令，用于更新 composer.json 中依赖的最小版本约束（如 "^2.8"→"^3.0"），不修改锁文件或安装包；需配合 composer update 使用，且不校验兼容性或 BC 变更。
Composer 2.5+ 才有 bump 命令
这个命令不是老版本 Composer 自带的，它从 2.5.0 开始才正式加入。如果你执行 composer bump 报错说“Command ‘bump’ is not defined”，先运行 composer --version 确认版本。低于 2.5 的必须升级：composer self-update（或用 php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');" && php composer-setup.php && sudo mv composer.phar /usr/local/bin/composer 手动更新）。
composer bump 默认只改 composer.json 中的最小版本约束
它不会自动 composer update，也不会修改锁文件或安装新包——只改声明。比如你当前依赖是 "monolog/monolog": "^2.8"，执行 composer bump monolog/monolog 后会变成 "monolog/monolog": "^3.0"（升到下一个主版本下限），但前提是该包已发布 v3.x 系列且符合语义化版本规则。
- 不加参数时，
composer bump会尝试把所有直接依赖的约束“推到最新兼容主版本起点”，风险较高，慎用 - 推荐始终指定包名：
composer bump vendor/package-name - 支持
--minor（升小版本下限，如^2.8 → ^2.9）和--patch（如^2.8.1 → ^2.8.2），但仅当目标版本实际存在时才生效 - 它识别
^、~、>、>=等约束写法，但对*或dev-main这类不明确的约束不做处理
为什么 bump 后要立刻 composer update vendor/package-name
bump 只改声明，composer.lock 里还是旧版本。如果不手动 update，下次部署或 CI 构建时仍会装旧版，导致声明与实际脱节。常见误操作是 bump 完就提交，结果测试环境跑的还是 v2.8.x。
- 安全做法：执行
composer bump foo/bar && composer update foo/bar --with-dependencies - 如果想批量 bump 多个包再统一 update，建议分步：先
bump a b c，再update a b c，避免锁文件冲突 - 注意
require-dev里的包也会被 bump 影响，如有测试专用依赖（如phpunit/phpunit），需确认是否真要升级其约束
真实项目中容易忽略的边界情况
它不检查依赖兼容性。比如你 bump laravel/framework 到 ^11.0，但项目里还用了已被移除的 Illuminate\Support\Str::macro()，bump 不报错，update 阶段才会暴露问题。
- 私有仓库或 VCS 包（如
"myorg/mylib": "dev-main"）无法自动 bump，命令直接跳过 - 如果某包在
require和require-dev中都出现，且约束不同，bump会分别处理两者，可能造成不一致 - 使用
platform配置（如"php": "8.1"）时，bump 不校验新约束是否仍兼容该平台版本
本质上，bump 是个“快速编辑器”，不是升级向导。真正决定能不能升、怎么升，还得靠人看 CHANGELOG、跑测试、查 BC break 文档。
