composer show -t 是当前唯一稳定、无需插件、能读取真实安装快照的依赖树命令，但必须指定包名（如 . 或 guzzlehttp/guzzle），不加会报错；--tree 参数在 composer 2.5+ 已移除。
直接说结论：composer show -t 是当前唯一稳定、无需插件、能读取真实安装快照的依赖树命令，但它必须指定包名（比如 . 或 guzzlehttp/guzzle），不加包名会报 Not enough arguments；--tree 参数在 Composer 2.5+ 已彻底移除，别再试了。
为什么 composer show -t 只显示一行或没缩进
这不是命令失效，而是环境没就绪。它只读 vendor/ 和 composer.lock 的实际内容，不解析 composer.json 的理想状态。
- 如果
vendor/为空或缺失，它只会输出项目名（如your-project-name dev-main），后面没任何缩进 -
composer.lock不存在、损坏或格式异常时，Composer 无法还原已安装包的版本和依赖路径，结果就是“空树” - 某些包被跳过安装（比如声明了
"ext-redis": "*"但 PHP 没启用 redis 扩展），它们不会进vendor/，也不会出现在树里 - 终端宽度太小导致换行错位，缩进视觉混乱——建议加
| less -S或重定向到文件：composer show -t . > deps.txt
composer show -t 的正确用法和参数顺序
参数顺序非常关键，错一位就失效。它不是“支持任意顺序的通用选项”，而是严格按解析逻辑执行。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 查整个项目依赖树（等效旧版
--tree）：composer show -t .（点号不能省） - 只看某个包的下游依赖（比如
monolog/monolog）：composer show -t monolog/monolog - 过滤开发依赖（生产环境分析）：
composer show --no-dev -t .（--no-dev必须在-t前） - 包含开发依赖：
composer show -t --dev .（--dev放最后才生效） - 查未安装包的潜在依赖（安装前评估）：
composer show --remote -t monolog/monolog
缩进不是调用链，也不是加载顺序
每级缩进只表示“谁在 composer.json 的 require 字段里写了它”，不是自动加载顺序，也不反映运行时类调用路径。
- 看到
guzzlehttp/guzzle下缩进出现psr/http-client，说明 Guzzle 自己声明了这个依赖 - 同一包在不同缩进层级反复出现（比如 2 级和 4 级都出现
symfony/polyfill-php80），大概率是多个上游包各自引入，需比对括号里的实际安装版本（如[v1.28.0]）是否一致 - 输出里带
[dev-master]或[7.8.1]的括号内容，是你composer.lock里锁定的真实版本，不是composer.json写的约束 - 如果看到
v6.5.8但你写了"^7.0"，说明有其他包强制降级了它，得顺着缩进往上翻找源头
反向查“谁用了这个包”，别用 depends
composer depends 是实验功能，默认关闭，遇到 provide、replace 或本地 path 仓库时容易漏判。真正可靠的是 composer show --who。
- 查谁直接依赖了
psr/log：composer show --who psr/log - 过滤开发依赖：
composer show --who --no-dev psr/log - 结果为空 ≠ 没人用 —— 可能是通过虚拟包（如
psr/log-implementation）间接提供，此时应回头看composer show -t .全局结构 - 想确认是不是你自己
composer.json里写的：composer why --tree monolog/monolog，末尾出现your-project-name dev-main才算溯源成功
依赖树不是静态文档，它是 composer.lock 的实时解析结果。只要 lock 文件没提交、没更新，你在本地看到的树，和 CI 上跑出来的就不一样——这点最容易被忽略，也最难排查。
