composer show -t 不支持 --max-depth，因 composer 2.5+ 已移除 --tree 并禁用该参数；必须用 composer show -t vendor/package-name 聚焦单点或 composer show --no-dev -t . 过滤开发依赖。
composer show -t 在中文镜像下仍不支持 --max-depth
无论你配了阿里云、腾讯云还是华为云镜像，composer show -t 的行为完全由 Composer 版本决定，和镜像源无关。Composer 2.5+ 已移除 --tree 参数，统一用 -t，但它**不接受 --max-depth**。运行 composer show --max-depth=2 -t . 会被静默忽略，输出仍是全量树。
验证方式很简单：composer --version。若为 2.5.x 或更高，就别在命令里写 --max-depth——它不是配置错了，是根本不存在。
- 真正有效的替代是聚焦单点：
composer show -t guzzlehttp/guzzle，只展开该包及其下游，比限制深度更可控 - 终端宽度不足时缩进错位，视觉上“同一级”实际层级不同，建议重定向查看：
composer show -t . > deps.txt - 中文镜像只加速元数据下载，不影响解析逻辑；但若你本地
composer.json里写了中文路径的path仓库，show -t可能截断或乱码，这不是镜像问题，是 Composer 原生命令不处理非 ASCII 路径
--no-dev 必须写在 -t 前面，否则无效
国内用户常因开发依赖爆炸导致依赖树动辄上千行，关键路径被淹没。比如 phpunit/phpunit 拉进一堆旧版 symfony/polyfill，掩盖了真实生产链路。这时过滤 require-dev 是刚需，但参数顺序错了就白干。
composer show -t --no-dev . 等价于 composer show -t .，--no-dev 被当成对 -t 的修饰而丢弃。正确写法必须是：composer show --no-dev -t .
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 漏掉这一步，输出可能膨胀 3–5 倍，尤其当项目用了
infection、phpstan这类重型工具时 - 如果
composer show --no-dev -t .输出仍极长（>200 行），说明生产依赖本身已过深，该考虑用replace或conflict收口，而不是靠眼睛扫 - 注意：此参数只过滤已安装的
require-dev包，不会影响composer.json中未安装的 dev 依赖声明
查“谁在拉这个包”，别信 composer depends
composer depends 是实验功能，默认关闭，且对 provide、replace 和本地 path 仓库识别极差。你看到空结果，不代表没人用——很可能是某个包通过 "psr/log-implementation": "monolog/monolog" 虚拟提供，depends 完全看不见。
可靠方式只有两个：
-
composer why --tree vendor/package-name：必须加--tree，末尾出现your-project-name dev-main才算确认是你自己写的require -
composer show --who vendor/package-name：直接扫描所有已安装包的require字段，结果确定性高；加--no-dev可排除测试工具干扰 - 如果
composer show --who返回空，但vendor/下确实有该包，大概率是被provide或replace引入，此时应回看全量树：composer show -t . | grep -A 3 -B 1 "vendor/package-name"
深度冲突时，prohibits 比 why-not 更准，但必须带完整版本号
当你想升级某个包却失败，composer why-not vendor/package 只查 composer.json 里写了但没装上的包；而 composer prohibits 是从你想装的那个**具体版本**出发，反向翻出所有拦路的约束，精度更高。
例如执行 composer prohibits laravel/framework:11.0.0，输出里会明确写出：spatie/laravel-backup v7.2.0 requires symfony/console ^5.4——这才是真正卡死你的源头。
- 必须写完整版本号，如
laravel/framework:11.0.0，不能写^11.0，否则报[InvalidArgumentException] Package not found - 每行末尾的
(for spatie/laravel-backup v7.2.0)就是你要动手调的包，不是laravel/framework本身 - 如果
prohibits没输出，说明问题不在已安装包，而是require-dev里的工具（比如phpunit/phpunit拖进旧版symfony/console），此时应先跑composer show --no-dev -t .排除干扰
vendor/ 和 composer.lock 的当前快照，不是 composer.json 的理想状态。改了 composer.json 却没 update，show -t 还是旧的；删了 vendor/ 但没删 composer.lock，install 仍照旧锁文件解压——这些细节不厘清，再准的命令也查不到真问题。
