composer show 是查看当前项目已安装包的最轻量命令，默认仅显示顶层依赖；加 –dev 包含开发依赖，–tree 展开完整依赖树，–platform 查看平台包，depends 反向查依赖，installed.json 为权威安装快照。
composer show 查看当前项目所有已安装包
直接运行 composer show 就能列出全部已安装的包及其版本，这是最常用、最轻量的方式。它默认只显示顶层依赖（你手动 require 的），不展开 require-dev 或嵌套依赖。
常见错误现象：执行后什么都没输出，或提示 “No packages installed”——大概率是当前目录不是 Composer 项目根目录（即没有 composer.json 和 vendor/）。先 ls composer.json 确认位置。
- 加
-s参数可显示包的简短描述：composer show -s - 加
--dev才会包含开发依赖：composer show --dev - 想看某个具体包的详细信息（比如它的依赖树）：
composer show monolog/monolog
composer show –tree 查看完整依赖树
当你要排查为什么某个包被装进来了，或者怀疑有冲突/重复加载时，composer show --tree 是关键命令。它会展开所有间接依赖，层级缩进显示，一眼就能看出谁拉入了哪个版本的 symfony/Event-dispatcher。
注意：这个命令输出很长，尤其在大型项目里。别直接滚屏找，用 composer show --tree | grep "package-name" 快速定位；也别在 CI 脚本里无条件用它——性能开销比 show 高不少，因为要解析整个依赖图。
- 它默认只显示生产环境依赖；加
--dev才包含开发依赖树 - 如果看到同一包多个版本并存（比如
psr/logv1 和 v3），说明存在兼容性断裂风险，得检查composer.json中的conflict或replace配置 - 某些包（如
php自身或平台包）不会出现在树里，它们属于 Composer 的“平台配置”，查composer show --platform
composer depends 检查某个包被谁依赖
当你想删掉一个包，但不确定会不会影响其他组件，就用 composer depends 反向查依赖关系。比如删 guzzlehttp/psr7 前，先跑 composer depends guzzlehttp/psr7，看哪些包显式或隐式依赖它。
容易踩的坑：这个命令默认只查“直接依赖者”，也就是一级上游；如果某包是通过中间包引入的（比如 A → B → C），composer depends C 不会显示 A。这时候得配合 --tree 或手动翻 vendor/composer/installed.json。
- 加
--recursive可递归查到所有间接依赖者（但输出可能混乱，慎用） - 加
--no-dev排除开发依赖的引用，避免误判 - 返回空结果 ≠ 完全没被用到，可能是通过 autoloading 或运行时 require 加载，得结合代码搜索确认
vendor/composer/installed.json 是真实依赖快照
命令行结果都是实时生成的，而 vendor/composer/installed.json 是 Composer 实际写入的权威记录——它包含每个包的安装路径、版本、源类型（dist/git）、autoload 配置，甚至哈希值。调试 autoload 错误或验证 lock 文件是否生效时，这里比命令更可靠。
注意：这个文件是二进制友好的 JSON，但结构较深，别手写修改。它不包含未安装的包（比如 require-dev 但当前没装的），也不反映 composer.lock 里声明但尚未 install 的状态。
- 用
jq '.packages[] | select(.name == "laravel/framework")' vendor/composer/installed.json快速提取某包元数据 - 如果发现
composer show和该文件内容不一致，说明 vendor 没同步更新，先composer install或composer update - CI 环境中有时会删掉
vendor/后只靠composer.lock恢复，这时installed.json就是唯一可信来源
依赖分析这事，命令只是入口，真正麻烦的是理解版本约束怎么生效、为什么 ^2.0 会装出 2.9.5 却拒绝 3.0.0、以及 replace 和 provide 怎么悄悄绕过版本检查——这些得看 composer.json 里的实际字段，而不是只盯命令输出。