Composer 不支持一键跨主版本升级，因 require 命令会强制重写约束并可能引发冲突；正确做法是先放宽版本约束或用 composer require vendor/package:^N.0 --with-all-dependencies 逐个升级，配合 outdated 检查与人工验证。
Composer 默认不会跨主版本升级依赖，composer update 只会在 composer.json 中已声明的版本约束范围内更新（比如 "^2.5" 不会升到 3.x）。想批量升到最新主版本，不能靠 require 命令直接“升级”，它本质是添加新依赖——误用反而会重复安装、破坏锁定或引入冲突。
为什么 composer require vendor/package 不能用来升级
执行 composer require foo/bar 时，Composer 会：
- 检查当前是否已存在该包：若存在，且未指定版本，则默认使用
^latest（如最新3.x），但会强制写入composer.json—— 即使原来用的是2.8，也会变成"foo/bar": "^3.0"，相当于手动改约束再 update； - 若该包被其他依赖间接引用，还可能触发不可预知的兼容性降级或冲突；
- 对已安装的多个包逐个
require并不等价于“批量主版本升级”，因为没统一处理依赖图和冲突回溯。
真正可行的批量主版本升级方法：先放宽约束，再 update
核心思路是让 Composer 在 update 阶段“被允许”跨主版本选择。需分步操作，且必须人工核验：
- 打开
composer.json，将所有依赖的版本字符串替换为宽松约束：
–"^1.2"→"^2.0"（升到 v2）或"*"（不推荐，太激进）；
– 更安全的做法是统一改为"^0.0 || ^1.0 || ^2.0 || ^3.0"（适用于支持多主版本的包，但极少有人这么写）； - 实际推荐：用
composer require --update-with-dependencies配合显式版本号，例如：composer require monolog/monolog:^3.0 --update-with-dependencies
； - 若要一次处理全部，可先用脚本提取所有顶层依赖名，再循环执行
require vendor/name:^N.0（N 为期望主版本），但必须确保每个包当前主版本与目标主版本之间有明确兼容路径。
更稳妥的替代方案：使用 composer upgrade 插件或手动控制
官方无内置“升到最新主版”命令，但可用社区工具辅助判断范围：
- 安装
hirak/prestissimo（加速）和phpstan/extension-installer（无关，仅举例）没帮助；真正有用的是：composer global require wilderun/installers
不适用；应换用：composer global require composer-unused/composer-unused
（检测未用依赖）——但这不解决升级问题； - 实用做法：运行
composer outdated --major-only查看哪些包有新主版本； - 然后对每个结果，查其 CHANGELOG 和 BC break 列表，再执行：
composer require vendor/package:^3.0 --with-all-dependencies
（--with-all-dependencies会连带升级其子依赖，比--update-with-dependencies更彻底）； - 切记：每次只处理 1–3 个高优先级包，跑完测试再继续，避免一次性爆炸。
跨主版本升级从来不是一键操作。最易被忽略的是：即使 composer update 成功，也不代表应用能跑通——Laravel 的 6.x → 7.x、Symfony 的 4.4 → 5.0 都要求大量代码适配。约束改得再准，没过单元测试和功能验证，就只是制造了幻觉。
