composer why 是唯一靠谱的命令，它直接读取 composer.lock 中的真实安装记录，不依赖配置开关，能回溯已安装包的依赖源头，支持 --tree 展开完整路径，且可处理虚拟包和 require-dev 场景。

直接用 composer why，别试 composer depends —— 后者在多数项目里根本不存在，或默认禁用，纯属干扰项。

为什么 composer why 是唯一靠谱的命令

它读的是 composer.lock 里的真实安装记录，不依赖配置开关，不区分 require / require-dev（加 --dev 可筛选），也不需要提前启用实验功能。只要包已装进 vendor/，它就能回溯到源头。

• 不加参数：只显示一级直接依赖者，例如 laravel/framework → monolog/monolog
• 加 --tree：展开完整路径，直到你的项目根包，比如 your-project-name dev-main，这才是真正触发安装的地方
• 如果输出为空，不是命令错了，而是这个包根本没被安装进当前 vendor/ —— 运行 ls vendor/monolog/monolog 确认存在性

composer why --tree 输出中断在某一层？大概率是虚拟包

比如查 psr/log，why --tree 可能停在 symfony/console 就断了。这不是命令失效，而是 symfony/console 通过 "provide": {"psr/log": "*"} 声明了该接口，并未实际 require 它。

Discussion Composer

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

下载

• 这种情况下，composer show --tree symfony/console 也看不到 psr/log
• 想定位真实提供者，得手动搜：composer show --tree | grep -B2 -A2 "psr/log"
• 或者检查 vendor/composer/installed.json 里 psr/log 对应的 type 字段是否为 virtual

查不到？先绕过三个常见卡点

90% 的“查不到”问题都出在这三处，而不是命令本身：

• 目标包只在 require-dev 里，但你没运行 composer install --with-all-dependencies 或 composer install（默认跳过 dev）
• composer.json 里写的是 monolog\monolog（反斜杠）或 Monolog/Monolog（大小写混用），而正确格式必须是全小写 + 正斜杠：monolog/monolog
• composer.lock 过期，比如你改了 composer.json 但没 composer update，why 仍按旧 lock 文件查

真正复杂的地方在于：Composer 不会告诉你“代码里哪一行用了它”，只告诉你“谁在 composer.json 里声明了它”。如果一个包是通过动态类名、配置文件、或 DI 容器注入进来的，why 无能为力 —— 那已经超出依赖管理器的职责范围了。