唯一稳定查已安装包依赖树的方式是 composer show --tree，它基于真实 vendor/ 和 composer.lock 输出实际安装的正向依赖链，加包名可聚焦查看，缩进表示 lock 文件中的嵌套顺序；查反向依赖用 composer why --tree，需确认包已安装并注意 provide 机制导致的链路中断。
直接用 composer show --tree 查已安装包的依赖树，这是唯一稳定、无需额外配置、且基于真实 vendor/ 和 composer.lock 的方式。别试 composer tree 或默认启用 composer depends——前者不是内置命令，后者在 2.4+ 中仍是实验功能，且行为不一致。
查“这个包依赖了谁”：用 composer show --tree vendor/name
它输出的是当前项目中**实际安装成功**的正向依赖链，不是 composer.json 里写的理想状态。
- 必须在项目根目录执行，且
vendor/已存在（即已运行过composer install） - 不加包名会打印整个项目的依赖树，几百行起步，基本没法扫；加包名才聚焦，比如
composer show --tree guzzlehttp/guzzle - 缩进代表层级，但不是“调用深度”，而是 Composer 解析后写入
composer.lock的嵌套顺序 - 终端宽度太窄会导致缩进错位，建议加
| less -S横向滚动查看 - 带
[dev]标记的条目说明来自require-dev，上线部署时不会被装
查“谁在用这个包”：用 composer why --tree vendor/name
它回答的是“为什么这个包被装进来了”，不是“谁在代码里 new 了它”。关键在 --tree —— 不加只显示第一层（比如只返回 laravel/framework），加了才能看到源头是不是你自己的 your-project-name dev-main。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 包必须已安装，运行
ls vendor/vendor/name确认存在 - 默认不查
require-dev下的链路；如果目标包只被phpunit/phpunit引用，得加--dev参数 - 若链路中断在某一层（比如停在
symfony/console就没了），大概率是它通过"provides": {"psr/log": "*"}声明满足了目标包，Composer 不再向下追踪 -
composer show --who vendor/name是轻量替代，但不支持--tree，只列直接依赖者
为什么 composer depends 总查不到或报错
它不是 why 的增强版，而是设计目的不同的命令：只扫描你项目 composer.json 中显式声明的 require 和 require-dev，完全不读 vendor/ 里的嵌套 composer.json。
- 执行前必须手动启用：
composer config experimental.show-depends true（仅对当前项目生效） - 即使启用了，也只返回“谁在
composer.json里写了它”，不展开间接路径（A→B→C 只显示 B） - 不区分
require和require-dev，也不显示版本约束（比如是"^2.0"还是"~1.8"） - 返回空 ≠ 包没被用，大概率是它根本没出现在
vendor/和composer.lock中——先跑composer show确认是否已安装
真正复杂的地方在于：Composer 的依赖解析是动态的，composer show --tree 显示的是 composer.lock 解析后的快照，而 composer.json 里写的只是约束条件。一旦 lock 文件滞后、平台配置（如 platform）掩盖了真实环境，或者某个包通过 provide 虚拟声明替代了另一个，依赖树就会和直觉不符——这时候不能只看命令输出，得去翻 composer.lock 里的 packages 字段，或用 composer show -s 看 solver 实际选中的版本。
