composer show是唯一靠谱的包信息查询命令，因为它直接读取vendor/composer/installed.json这一磁盘真实快照，不联网、不依赖composer.lock，断网或锁文件损坏时仍准确；默认只显示composer.json中require和require-dev声明的顶层依赖，查单个包需全名如monolog/monolog，报“package not found”即未实际安装。
直接用 composer show，别碰 composer list —— 后者只列命令，不查包。
为什么 composer show 是唯一靠谱的命令
它读的是 vendor/composer/installed.json，这个文件是 Composer 安装完成后写入的“事实快照”，不联网、不解析 composer.lock，只反映磁盘上真实装了什么。哪怕断网、composer.lock 损坏，只要 vendor/ 目录完好，composer show 就能返回准确结果。
常见误判点：
- 输完
composer show发现输出空或只有几个包？默认只显示你手动写在composer.json的require和require-dev里的顶层依赖，不是vendor/下全部目录 - 刚克隆项目但还没运行
composer install？composer show仍可能有输出——它会 fallback 到composer.lock，但此时显示的是“计划安装”，不是已解压的包 - 执行过
composer install --no-dev？phpunit/phpunit这类开发依赖就不会出现在结果里，哪怕它们还在composer.json中
composer show 查单个包的真实版本
想确认项目里实际跑的是哪个版本，必须用 composer show vendor/package-name（比如 composer show monolog/monolog），输出中 versions 行就是当前生效版本，例如 v3.5.0 或 dev-main。
注意：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 包名大小写敏感：
symfony/console和Symfony/Console是两个不同包 - 不加
-a时，versions字段只列本地缓存中“曾安装过或已知”的版本，不是 Packagist 全量列表 - 如果报
Package not found，说明该包确实没装进vendor/，不是命令错了
查完整依赖树和导出清单
要搞清谁依赖了谁、为什么装了两个 psr/log 版本，必须用 composer show --tree。它还原的是 composer.lock 解析出的实际安装路径，缩进结构一目了然：
laravel/framework v10.48.12
└── symfony/console v6.4.7
└── psr/log 3.0.0
导出干净文本清单供审计或 CI 使用：
- 一行一个
vendor/name version：composer show --installed --no-ansi - 只导出你亲手
require的包（不含子依赖）：composer show --direct --format=plain - 导出带缩进的树形文本供人工审阅：
composer show --tree --format=txt > dependencies.txt
全局包不能用 composer show 查
composer show 只看当前项目，对全局安装的工具（如 laravel/installer）完全无效。查全局包必须用：
-
composer global show：列出所有全局已安装包 -
composer global show laravel/installer：查指定全局包
全局包路径通常为 ~/.composer/vendor/（Linux/macOS）或 %APPDATA%\Composer\vendor\（Windows），但别手动翻目录——global show 才是最可靠方式。
真正容易被忽略的是：当你在项目里查不到某个包，第一反应不该是“是不是没装”，而是先确认它属于项目级还是全局级；再检查是否用了 --no-dev 或 --no-install 类参数跳过了安装步骤。
