^9.0与^10.0不兼容，因semver规定主版本变更（9→10）视为不兼容；^9.0仅允许9.x.x，禁止升至10.0.0，需手动升级并校准整个依赖图。
Composer 本身不提供直接的版本比较命令，但可以通过 composer show、composer depends 和语义化版本规则手动比对依赖兼容性。
怎么看两个包版本是否兼容（比如 laravel/framework ^9.0 vs ^10.0）
Composer 的依赖解析完全基于 SemVer 2.0 规则，不是字符串比大小。关键看约束符含义：
-
^9.0表示允许9.x.x，但不允许升到10.0.0（主版本变更视为不兼容） -
~9.2.0等价于>=9.2.0 ，只允许补丁和次版本微调 -
*或dev-main这类非稳定写法无法用 SemVer 比较，必须人工确认变更日志
实际判断时，打开 composer.json 查 "laravel/framework" 的约束值，再对照目标版本号——只要目标版本满足约束表达式，就“技术上可安装”，但不等于“业务上安全”。
为什么 composer update foo/bar 有时升级了其他包？
因为版本约束存在传递依赖。例如：
foo/bar ^2.1 → requires bar/baz ^3.0<br>your-project → requires bar/baz ^3.2
此时 composer update foo/bar 可能触发 bar/baz 从 3.2.1 升到 3.4.0，以同时满足两者约束。常见诱因包括：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 多个包共同依赖同一个底层库（如
symfony/polyfill） - 使用了宽松约束（
^或*），而新版本发布后 Composer 自动选最新兼容版 -
composer.lock被删或未提交，导致每次update都重新解析全图
如何安全地验证版本升级影响？
别只信 composer update --dry-run，它只模拟安装，不校验运行时行为。真实验证要分三步：
- 先用
composer prohibits vendor/package:version检查冲突（例如composer prohibits laravel/framework:10.0） - 再跑
composer update vendor/package:version --with-all-dependencies，观察是否连带升级了不该动的包 - 最后执行
git diff composer.lock，重点看packages和packages-dev下实际变更的版本号，尤其注意主版本跳变（如8.x → 9.x）
很多线上故障源于忽略了 composer.lock 中某行看似无关的 "monolog/monolog": "3.5.0" 实际被拉高了主版本——它可能破坏你自定义的日志处理器接口。
什么时候该手动锁死子依赖版本？
仅当子依赖出现 BC Break 且上游未及时修复时才需干预。典型场景：
- 你的代码直接用了
guzzlehttp/guzzle的Promise类，但项目里没直接 require 它，而是通过laravel/framework间接引入；某次laravel/framework小版本升级悄悄把guzzle从7.5升到8.0，导致 Promise 接口变更 - 你发现
phpunit/phpunit从9.6升10.0后测试失败，但又不能立刻升级整个测试栈
此时可在 composer.json 中显式加一行："guzzlehttp/guzzle": "7.5.*" 或 "phpunit/phpunit": "^9.6"，强制覆盖传递依赖的版本选择。但要注意：这会抑制 Composer 的自动优化，后续需自行跟踪安全更新。
