不能靠一个 composer require 命令批量改多个包的版本约束，因其默认拒绝重复声明且不覆盖已有条目；必须分两步：先用 --no-update 安全写入新约束，再用 composer update 指定包精准重算。
不能靠一个 composer require 命令批量改多个包的版本约束——它根本拒绝重复声明，也不会覆盖已有条目。真正可控的做法，是分两步：先安全写入新约束，再精准触发重算。
为什么 composer require foo/bar:^3.0 会报错“Package is already present”
Composer 默认把 require 当作「新增依赖」操作，不是「更新约束」。只要 foo/bar 已在 composer.json 的 require 或 require-dev 里存在，无论版本号是否不同，都会直接报错。
- 错误现象：
[InvalidArgumentException] Package foo/bar is already present in require - 这不是权限或网络问题，是设计逻辑：Composer 不允许模糊覆盖，避免意外降级或约束冲突
- 想改约束，必须显式移除旧条目，或绕过校验机制
- 最稳妥路径：用
--no-update强制写入新约束，再单独update目标包
如何安全批量修改多个包的版本约束
核心是把「写配置」和「执行求解」彻底分开，避免中间状态污染。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 逐个执行
composer require foo/bar:^3.0 --no-update，每条命令只改一个包，不碰vendor和composer.lock - 确认
composer.json已更新后，运行composer update foo/bar bar/baz --with-dependencies，只重算列出的包及其直系依赖 - 绝对不要用
composer update（无参数），它会全量重算，可能连带升级你没动过的包，导致 CI 失败 - 如果涉及 dev-only 包（如
phpunit/phpunit），务必加--dev，否则会被误写进require段，引发部署告警
composer update 后版本没变？三个关键检查点
改完 composer.json 并执行了 update，但实际安装的还是旧版，大概率卡在以下环节：
-
composer.lock里还锁着旧版本：Composer 优先复用 lock 文件，除非明确要求重算。可删掉 lock 中对应条目，或用composer update --lock只刷新 lock - 其他包在拖后腿：运行
composer why-not foo/bar:3.0.0，看哪个依赖硬性限制了最高版本；再用composer depends foo/bar顺藤摸瓜查间接依赖 - 约束本身有隐性冲突：比如你写了
"^3.0, !=3.2.0"，但可用版本只有3.2.0和4.0.0，那结果就是无解。用composer show foo/bar看它到底发布了哪些稳定版
批量改约束最易被忽略的点，是忘了检查 composer.lock 是否已提交——它才是最终生效依据。改完 composer.json 不 update，别人 install 还是旧版本；update 了不提交 lock，CI 就跑不出一致结果。这两个动作缺一不可。
