“Composer图层搜索”并非真实功能，实为对composer show -t或composer depends -t输出缩进结构的误称；二者仅静态展示vendor/与composer.lock当前快照中的依赖层级，不支持动态搜索、过滤或图谱构建。
“Composer图层搜索”不是真实存在的功能，它只是对 composer show -t 或 composer depends -t 输出结构的误称——这些命令不搜索，只展示当前已安装依赖的快照层级。
为什么没人能搜到“图层”
Composer 本身没有图层索引、拓扑扫描或反向依赖图谱构建能力。所谓“图层”，其实是 composer show -t 把 vendor/ 里已安装包的依赖关系用缩进格式打印出来，本质是静态树形渲染，不是动态搜索：
- 它只反映
composer.lock和vendor/的当前状态；删过包、改过composer.json却没install，树就过期 -
composer depends -t symfony/console返回空，不代表没人用它——可能是通过autoload手动引入，或由插件在运行时注册 - 不支持按 PHP 版本、扩展、稳定性（
dev/stable）过滤图层节点
composer show -t 和 composer depends -t 的真实用途
这两个命令适合做「现场诊断」，而非「探索发现」：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
composer show -t：快速确认某个包（如monolog/monolog）是否被间接引入、由谁带入、是否重复加载（比如两个不同版本共存） -
composer depends -t vendor/package：查清谁在 require 它——但结果仅限于显式写在composer.json中的依赖，不包含require_once或插件机制加载的 - 输出无超链接、无跳转、无交互；想定位某一层的具体文件？得靠
grep -r "class_name" vendor/配合手动翻
真要定位“深层依赖”该怎么做
当你要确认一个类/函数最终来自哪个包、哪个版本、是否被多层代理包装时，不能依赖树形输出，而应结合路径与符号追踪：
- 先用
composer show --all | grep -i "psr-4"粗筛可能注册了该命名空间的包 - 再进
vendor/找对应包的composer.json，看autoload配置是否映射到你要找的类 - 若涉及运行时动态加载（如 Laravel Service Provider），必须查项目中
config/app.php或ServiceProvider::register()实现 - 遇到类名冲突？用
php -r "var_dump(class_exists('SomeClass'));"+get_declared_classes()快速验证加载顺序
容易被忽略的关键点
依赖树不是活的——它不会告诉你某个包是否已被弃用、是否在 PHP 8.3 下崩溃、是否要求未启用的扩展（如 ext-igbinary）。你看到的每一层，都只是上次 composer install 时的快照。真正决定能否用的，永远是 composer require --dry-run 和 composer show vendor/package 显示的 requires 字段。
