composer show --tree 输出的是 vendor/ 目录中已安装包与 composer.lock 记录的实际解析结果，反映全局约束求解后的唯一可行依赖快照，非 composer.json 的理想声明；缩进表示直接 require 关系，括号内版本（如[2.9.2]）为真实安装版本，同一包多路径出现或版本不一致即提示潜在冲突。
Composer 不是“安装你写的版本”，而是求解所有约束后给出唯一可行解；依赖树不是调用链，只是声明依赖的快照。
composer show --tree 看到的到底是什么
它输出的是 vendor/ 目录下已安装包 + composer.lock 中记录的**实际解析结果**，不是 composer.json 里写的理想状态。缩进代表直接 require 关系，不是加载顺序或重要性。
- 同一包在不同缩进层级重复出现 → 很可能被多个上游包分别引入，版本不一致时就是冲突前兆
- 输出里带
[2.9.2]或[dev-main]→ 这才是真实装上的版本，括号外写的只是包名 - 没装这个包？命令直接报
Package not found，不会自动 fetch 或 fallback 到 remote - 终端宽度太小会导致缩进错位，建议加
| less -S或重定向到文件后用编辑器查看
为什么明明写了 "^3.0" 却装了 2.9.2
因为 Composer 是全局求解：所有已声明的 require、每个包自己的 require、conflict、甚至 platform 配置（比如 "php": "8.1.0"）全被扔进一个约束池，然后找唯一满足全部条件的版本组合。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 查谁卡住了升级：
composer prohibits monolog/monolog:3.0 - 查谁拉低了版本：
composer why monolog/monolog，再加--tree看完整路径 -
composer show --tree里看到的 2.9.2 是结果，不是原因；它不告诉你“为什么不能升”，只告诉你“现在是谁在用哪个版本” - 手动改
composer.lock中某个包的版本号？下次composer install可能被覆盖，composer update更会彻底重算
反向追踪依赖必须用对命令
composer depends 是个陷阱：2.4+ 才有、默认禁用、对 provide 和 replace 处理不稳。真正该用的是 composer show --who 和 composer why。
- 查“谁直接 require 了 psr/log”：
composer show --who psr/log - 查“我项目里哪行导致装了 symfony/http-kernel”：
composer why -t symfony/http-kernel - 只想看生产环境依赖谁用了它？加
--no-dev，否则 phpunit 拉进来的旧版 polyfill 会干扰判断 -
composer depends -r能递归列出所有间接依赖者，但它不显示路径深度，也没法区分 root 是你项目还是某个子包
依赖树不是终点，只是调试入口
看到树 ≠ 理解问题。缩进再深，也藏不住 conflict 声明、平台限制、或 provide "psr/log-implementation" 这类隐式替换。
- 发现某包有多个版本共存？立刻接
composer why-not vendor/package:3.0，看是否真不可行 - 想确认某个包是否真的被需要？先
composer remove vendor/package，再composer show --tree看有没有其他路径补上 -
composer show --tree --remote vendor/package可查未安装包的依赖结构，适合上线前评估风险 - 真要可视化整棵树？别硬啃文本，用
composer-unused+dot导出 Graphviz 图，不然靠数空格定位冲突，效率极低
