如何使用Composer管理直接依赖与间接依赖-composer-PHP中文网

composer将直接与间接依赖一视同仁交由sat求解器统一解析；require顺序无权重，php版本等约束冲突会导致整体失败；composer.lock仅锁定结果，不控制求解逻辑；应善用conflict、why-not和prohibits定位问题，install不解析而update才触发sat求解。

如何使用composer管理直接依赖与间接依赖

直接依赖写在 `require` 里，但解析时它和间接依赖完全平等

Composer 不会因为你亲手写了 "laravel/framework": "^10.0" 就给它更高权重。它把所有约束——包括你写的、guzzlehttp/guzzle 的 require、甚至 symfony/polyfill-mbstring 里的 conflict——全部扔进同一个 SAT 求解器里统一判断。一个间接依赖要求 "php": ">=8.2"，而你本地是 PHP 8.1，那整个求解直接失败，不管你的 require 多干净。

常见错误现象：

本地 composer install 成功，CI 报 Your requirements could not be resolved → 很可能 CI 的 PHP 版本低于某个间接依赖的最低要求
删掉 vendor 重装后类找不到 → composer.lock 没提交，install 退化成 update，SAT 求解器重新跑，选出了不同版本组合

间接依赖版本漂移的根本原因不是没锁，而是没控

composer.lock 确实锁住了当前解析出的所有包版本，但它只记录结果，不干预下次求解逻辑。只要有人执行 composer update 或删了 lock 文件重装，间接依赖就可能变——因为上游包自身 require 的版本范围（比如 "psr/log": "^2.0"）比你想象中松得多。

实操建议：

别指望 composer require --no-update 能稳住子依赖——它只是跳过安装，不改约束
用 "conflict" 字段在根 composer.json 中硬性排除你不想要的版本，例如：
```
"conflict": {
  "guzzlehttp/guzzle": ">=8.0.0",
  "monolog/monolog": "3.0.0"
}
```
conflict 规则只在 update 或无合法 lock 时生效，不影响已安装的包

`composer why-not` 和 `composer prohibits` 是定位冲突的唯二可靠命令

看到 Your requirements could not be resolved 别急着改 require 顺序或降级主包。Composer 的报错本身不指明谁在拦路，必须主动查。

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

使用场景：

composer why-not laravel/framework:10.40.0 → 查哪个包明确拒绝这个版本（输出可能是 spatie/laravel-backup 5.0.0 requires laravel/framework ^9.0）
composer prohibits monolog/monolog:2.9.0 → 验证你加的 conflict 是否被加载（有输出说明规则已参与求解）
这两个命令不触发安装或下载，纯分析，快且准