Composer update 不修改 composer.json 是因设计上将依赖实现更新与版本约束更新分离；前者自动执行，后者需人工确认以避免破坏语义化版本兼容性。
Composer 默认不会在 composer update 时自动修改根项目的 composer.json —— 它只更新 composer.lock 和依赖代码。想让版本约束也同步更新（比如把 "monolog/monolog": "^2.0" 升到 "^3.0"），必须显式触发交互式版本重写。
为什么 composer update 不改 composer.json？
这是 Composer 的设计原则：依赖升级和版本约束更新是两个独立动作。update 只解决「当前允许范围内，拉哪个具体版本」；而修改 composer.json 是「重新定义允许范围」，需人工确认，否则会破坏语义化版本边界或引入不兼容变更。
常见错误现象：
- 运行 composer update monolog/monolog 后，composer.json 里的版本号没变，但 composer.lock 里已装了 v3.x
- 下次 composer install 仍按旧约束装 v2.x，导致环境不一致
用 composer require --update-with-dependencies 交互式重写约束
这是唯一官方支持的、带交互提示的「连带更新 composer.json」方式。它会：先计算可升级路径 → 列出所有候选版本 → 让你逐个选是否收紧约束。
- 运行
composer require monolog/monolog --update-with-dependencies --interactive - 它会显示类似：
Do you want to update the version constraint for "monolog/monolog" in composer.json to "^3.4"? [y] Yes [n] No [a] Abort
- 选
y后，composer.json中对应行被重写，composer.lock同步更新 - 该命令只影响你明确指定的包及其直接依赖（由
--update-with-dependencies控制），不会扫全量
替代方案：手动 + composer prohibit 防误锁
如果交互式流程太重，更可控的做法是：先查清目标版本 → 手动改 composer.json → 再 update。但容易漏掉间接依赖的兼容性问题。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
建议组合使用：
- 查可用版本：composer show monolog/monolog --all | grep -E '^[0-9]'
- 编辑 composer.json，例如把 "^2.0" 改成 "^3.4"
- 运行 composer update monolog/monolog --with-all-dependencies（强制连带更新子依赖）
- 加一道防护：composer prohibit monolog/monolog:2.*，防止后续误装 v2 分支
别踩 composer update --lock 这个坑
这个参数常被误认为能联动更新 composer.json，实际它只是跳过依赖解析、仅重写 composer.lock —— composer.json 依然纹丝不动，且可能因约束过宽导致锁文件降级。
真正需要的是约束变更 + 锁文件同步，不是单纯锁文件刷新。只要没动 composer.json，就不是「更新约束」，只是「更新实现」。
交互式重写的本质，是把「人对版本边界的判断」显式注入到 composer.json 中。漏掉这步，协作项目里很容易出现 lock 文件和 json 不一致、CI 构建结果漂移的问题。
