composer show -t 依赖树完全基于 composer.lock 文件递归展开，不读 vendor/ 目录也不解析 composer.json；删 vendor/ 但保留 lock 文件仍可输出完整树，终端宽度不足会导致缩进错位，可用 | less -S 或重定向查看。
composer show -t 显示的依赖树到底从哪来
它不读 vendor/ 目录，也不动态解析 composer.json，而是完全基于 composer.lock 文件递归展开。锁文件里怎么记的，composer show -t 就怎么输出——哪怕你删了 vendor/ 但没动 lock，它照样能跑出完整树。
常见误判点：
- 终端宽度不够时缩进错位，导致父子关系看串 → 加
| less -S或重定向到文件：composer show -t > deps.tree - 执行过
composer install --no-dev后，require-dev里的包（如phpunit/phpunit）不会出现在树里，哪怕它们还在composer.json中 - 某包在树里出现多次、版本不一致（比如
symfony/console一次是^5.4，一次是^6.4），说明存在隐式冲突，不是配置漏写，是上游约束打架
为什么 composer show -t monolog/monolog 报错 “Package not installed”
这个错误和 composer.lock 无关，只说明该包当前没解压进 vendor/。可能原因包括：
- 你刚克隆项目，
composer.lock存在但还没运行composer install - 该包只写在
require-dev里，而你上次用了--no-dev安装 -
conflict规则把它踢出了安装计划（比如monolog/monolog和另一个包互斥） - 手动删过
vendor/但没重装，或用composer update --lock只更新了锁文件
验证方式：直接 ls vendor/monolog，目录不存在就说明真没装。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
composer show -t 输出里哪些字段暴露真实冲突点
别只盯着包名，重点看每行末尾括号里的内容：
-
(locked to 5.4.32)→ 这个版本已被composer.lock固定，想升级必须删 lock 或加--with-all-dependencies -
[dev-main]或[2.9.0]→ 表示实际解析出的版本，不是composer.json里写的^2.0，可用于反查谁强制降级了它 - 同一包在不同缩进层级反复出现，且带不同
(locked to ...)→ 典型多路径引入+版本不兼容，立刻用composer why-not vendor/package:desired-version倒查阻断源
注意：composer show -t 不会标出 conflict 或 replace 关系，这些得靠 composer show vendor/package 单独查元数据里的 conflict 字段。
想快速定位某个包被谁拉进来，别硬翻树
用 grep 配合 -A/-B 精准截取上下文，比滚动找快得多：
- 查
guzzlehttp/guzzle是谁引入的：composer show -t | grep -B2 "guzzlehttp/guzzle" - 查它又被谁依赖（下游）：
composer show -t guzzlehttp/guzzle | grep -A3 "requires" - 确认是否被
require-dev拖入：composer show -t --no-dev | grep "guzzlehttp/guzzle"，如果没结果，说明它只存在于开发依赖链中
真正卡死的往往不是你写的顶层依赖，而是第二层包（如 symfony/console、psr/log）的版本被多个上游分别锁定。盯住这些枢纽包，比盯着 guzzle 或 monolog 更有效。
