Composer 依赖解析由求解器自动完成，冲突源于版本约束互斥而非递归未开启；用 composer why-not 定位冲突包，结合 --with-dependencies、COMPOSER_MEMORY_LIMIT 等参数控制求解行为，且必须提交 composer.lock 保证环境一致。
Composer 默认会递归解析依赖，但“深度处理版本关联”不是靠配置开关实现的，而是由 composer install 或 composer update 运行时的依赖求解器（Solver）自动完成的。你真正需要干预的，是约束条件本身和求解过程的可控性。
为什么 composer update 有时卡住或报错？
这不是递归没开启，而是 Solver 在尝试满足所有 require 中的版本约束（包括传递依赖）时陷入冲突或组合爆炸。常见现象：
Your requirements could not be resolved to an installable set of packages.- 命令长时间无响应（尤其在 CI 或低内存环境）
- 本地能装，CI 报错——往往因
composer.lock缺失或平台配置不一致
根本原因：某个包的子依赖链中存在互斥版本约束（比如 A 要求 monolog:^2.0，B 要求 monolog:^3.0），Solver 找不到交集。
用 composer why-not 定位冲突源头
别猜，直接查哪个包在阻止你升级或安装目标版本：
composer why-not monolog/monolog:3.0.0
输出会列出所有已安装包中，哪些 require 了与 monolog/monolog:3.0.0 不兼容的版本（例如 ^2.8 或 !=3.0.0）。这是处理深层依赖冲突最有效的第一步。
注意：why-not 只检查已安装状态；若尚未安装目标包，先运行 composer update --dry-run 看是否失败，再用 why-not 排查。
控制求解深度与行为的关键参数
Composer 没有“递归层数”配置项，但可通过以下参数影响 Solver 的策略和边界：
-
--with-dependencies：强制更新目标包及其所有直接依赖（不含间接依赖），适合局部修复 -
--no-update+ 手动改composer.json后再composer update --lock：跳过 Solver，只重写 lock 文件（危险，仅限你知道自己在做什么） -
COMPOSER_MEMORY_LIMIT=-1：防止因内存不足被 kill（尤其在 Docker 或 CI 中） -
"minimum-stability": "stable"和"prefer-stable": true在composer.json中：减少预发布版本引入的意外冲突
慎用 --ignore-platform-reqs：它绕过 PHP/扩展版本检查，可能让 Solver 找到“理论上可行但实际无法运行”的组合。
锁文件不是可选附件，而是依赖图的快照
composer.lock 记录了每个包（含全部嵌套依赖）的精确版本、校验和与来源。没有它，每次 composer install 都会重新运行 Solver——结果可能不同，尤其当远程包发布了新版本但未修改其 composer.json 的约束范围时。
团队协作中，必须提交 composer.lock。CI 环境应始终使用 composer install（而非 update），确保构建一致性。
真正容易被忽略的是：当你手动修改 composer.json 后只运行 composer install，Composer 不会更新 lock 文件中的其他依赖——它只按 lock 文件还原。必须显式运行 composer update vendor/package-name 或全量 update 才会触发 Solver 重算整个图。
