Composer怎么查看require约束_Composer当前约束查看方法【实用】-composer-PHP中文网

composer show --tree monolog/monolog 可直接查看该包在当前项目中被哪个顶层 require 拉入、实际安装版本及所依赖的其他包版本，输出基于 composer.lock 快照，需确保已执行 composer install/update。

composer怎么查看require约束_composer当前约束查看方法【实用】

composer show --tree 看当前已安装包及其依赖约束

想快速知道某个包（比如 monolog/monolog）在当前项目里被哪个顶层 require 拉进来、以及它实际装的是哪个版本、又依赖了哪些其他包的什么版本，composer show --tree 是最直接的命令。它会从 composer.json 的 require 出发，逐层展开依赖树，每行末尾标注的版本号就是 Composer 实际锁定的版本（来自 composer.lock）。

常见误操作：只跑 composer show（不加 --tree），结果只看到所有已安装包的列表，看不到谁依赖了谁、也看不出约束来源。

运行前确保已执行过 composer install 或 composer update，否则 composer.lock 未生成或过期，--tree 显示的版本可能不准
如果只想查某一个包，加包名参数：composer show --tree monolog/monolog
输出里带 [dev-master] 或 [dev-main] 这类字样，说明该包是通过 vcs 仓库以开发分支方式安装的，其 require 约束可能不体现在 composer.json 中，而来自该分支的 composer.json

composer depends 查某个包被谁 require

当你发现某个包（例如 symfony/polyfill-php81）占体积大、有安全警告，想确认是不是自己主动 require 的，还是被某个依赖间接拉进来的，就用 composer depends。它反向查依赖关系，列出所有直接或间接 require 了该包的包。

典型错误现象：运行 composer depends symfony/polyfill-php81 返回空，但 composer show 又能看到它已安装——这通常是因为它被 require-dev 里的包引入，而 composer depends 默认不查 require-dev。

要包含开发依赖，加 --tree 或 --recursive 参数：composer depends --recursive symfony/polyfill-php81
如果返回结果里出现 root，说明你项目根 composer.json 的 require 或 require-dev 直接写了它
注意区分 depends 和 show --tree：前者回答“谁用了它”，后者回答“它用了谁”

看 composer.json 和 composer.lock 里的实际约束字段

Composer 的约束最终生效靠两处：一是 composer.json 的 require 字段写的版本约束（如 "php": "^8.0"），二是 composer.lock 里记录的具体安装版本和哈希值。两者不一致时，composer install 严格按 lock 文件装，composer update 才会重新解析 composer.json 并更新 lock。

Discussion Composer

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

下载

容易忽略的细节：某些约束写法看似宽松，实际效果很窄。比如 "laravel/framework": "9.*" 等价于 "^9.0"，不会匹配 10.0；而 "9.0 - 9.9" 这种范围写法，如果中间缺了某个小版本（如没发布 9.5），Composer 会跳过它继续找可用版本，但人眼容易误判覆盖范围。

composer.json 中的 require 是声明式约束，不保证一定能装上——真正决定装哪个版本的是 composer.lock
修改 composer.json 后必须运行 composer update xxx（或全量 update）才能更新 composer.lock，仅改 JSON 不生效
用 composer validate 可检查 composer.json 格式是否合法，但不校验约束是否可满足

composer why-not 判断某个版本为什么装不上

当你执行 composer require some/package:2.0 报错，提示“your requirements could not be resolved”，但错误信息一堆依赖冲突，很难一眼看出卡在哪，这时 composer why-not 就是定位关键瓶颈的利器。它会告诉你：因为 A 包要求 B 包必须 ≥3.0，而你要装的 C 包只兼容 B 包 ≤2.5，所以冲突。

真实踩坑场景：升级 Laravel 时，composer update "laravel/framework:^10.0" 失败，运行 composer why-not laravel/framework:10.0 发现 spatie/laravel-backup 的最新稳定版只支持到 Laravel 9，它锁死了 illuminate/support 的版本范围，从而阻断了整个升级链。