Composer 不会设置递归依赖，而是自动解析整个依赖树；安装时出现未声明的包是因直接依赖的 composer.json 声明了它们；composer.lock 记录全部精确版本，删后重装可能引发兼容问题；update 默认升级整棵树，可用指定包名或 --lock 控制；冲突源于多层版本诉求不一致，应优先用 composer why-not 定位。
Composer 不会、也不能“设置”递归依赖——它只按 composer.json 显式声明的依赖解析，深层关联包由依赖图自动推导，不是靠手动开启或配置递归开关。
为什么 composer install 会装一堆没写在根 composer.json 里的包？
这是 Composer 的正常行为：它根据你声明的直接依赖（如 "monolog/monolog": "^2.0"），自动拉取这些包所依赖的其他包（比如 psr/log），再递归解析直到所有依赖满足。这个过程叫“依赖解析”，不是“递归启用”。
- 你没写
psr/log，但它出现在vendor/里，是因为monolog/monolog的composer.json声明了它 -
composer.lock记录的是整个依赖树的精确版本，包括所有间接依赖 - 删掉
composer.lock后重装，可能因版本约束松动导致深层包升级，引发兼容问题
composer update 为什么会升级深层包？怎么控制？
默认情况下，composer update 会更新整棵树——不只是你写的包，还包括它们的子依赖。这常导致意外升级（比如 guzzlehttp/psr7 从 v1 升到 v2，破坏 API 兼容性）。
- 只更新指定包及其子依赖：
composer update monolog/monolog - 完全禁止更新某深层包（锁定版本）：
composer require psr/log:1.1.4 --no-update，再composer update --lock - 用
replace或conflict在根composer.json中显式干预（慎用，易冲突）
遇到 Root composer.json requires ... but it is not satisfiable 怎么办？
这不是“递归太深”，而是依赖约束冲突：某个深层包被多个上游以互斥版本要求（例如 A 要 symfony/event-dispatcher:^5.4，B 要 ^6.0）。
- 运行
composer why-not vendor/package:version查谁在阻止安装 - 检查是否混用了 major 版本差异大的包（如 Laravel 9 + Symfony 7 组件）
- 临时降级某依赖（如改
"laravel/framework": "9.52.*"）比硬加force更安全 -
composer prohibits vendor/package:version比报错信息本身更直白
真正麻烦的从来不是“递归多深”，而是不同层级对同一包的版本诉求不一致——这时 composer.json 里一行 conflict 或一个 require-dev 里的测试工具，都可能成为破局点。
