最可靠的方式是解析 composer.lock 文件统计包数：用 jq 命令 jq '[.packages[] | select(.type != "metapackage" and .type != "project")] | length' composer.lock 或 PHP 脚本读取并去重计数，而非依赖 install/update 日志。
composer install 和 composer update 时如何知道装了多少包
Composer 本身不提供“安装总数”的直接统计命令，composer install 或 composer update 的输出里只有包名和版本号，没有计数汇总。你看到的是一行行下载/解压日志，不是可解析的统计结果。
真正能拿到数字的方式是查 vendor/ 目录下的实际包数量，或解析 composer.lock —— 它才是权威来源，记录了所有已解析并锁定的依赖（含递归依赖）。
-
composer.lock中的packages数组只包含直接依赖和一级间接依赖（即所有被实际安装的包），不含 dev-only 包（除非当前环境启用了--dev） - 如果想排除平台包（如
ext-json、php等虚拟包），得过滤掉type: "metapackage"或type: "library"以外的条目 - 运行
composer show --tree是人眼可读的树状结构，但不便于计数；它也不显示被替换（replace）或忽略（conflict）的包
用 jq 快速统计 composer.lock 中的包总数
前提是系统装了 jq（macOS 可用 brew install jq，Linux 用 apt install jq）。这是最轻量、最可靠的方式，绕过 PHP 解析开销，直读 JSON。
以下命令统计所有实际安装的包（不含 platform 包）：
jq '[.packages[] | select(.type != "metapackage" and .type != "project")] | length' composer.lock
若需包含 packages-dev（开发依赖），合并后去重再计数：
jq '[.packages[], (.packages-dev // [])[]] | unique_by(.name) | length' composer.lock
-
// []是 jq 的空值默认语法，避免packages-dev不存在时报错 -
unique_by(.name)防止同名包在packages和packages-dev中重复计数（虽然 Composer 通常不会这样，但 lock 文件结构允许） - 注意：这个数字 ≈ 实际
vendor/下的目录数，但不完全等价（例如某些包可能用install-path改了路径，或用了no-api模式）
PHP 脚本解析 composer.lock 获取包数（无外部依赖）
如果你不能装 jq，又不想手动打开 composer.lock 数，可以用一段小 PHP 脚本。它比 shell 更兼容 Windows，也更容易嵌入 CI 流程。
保存为 count-packages.php，然后运行 php count-packages.php：
- 跳过了
type: "metapackage"（如phpunit/phpunit的 meta 包）、"project"（根项目自身）、"plugin"（极少影响计数） - 用
name@version当 key，比单纯按 name 去重要严谨——比如monolog/monologv2 和 v3 共存时应算两个 - 该脚本不校验
composer.lock是否存在或格式是否合法，生产使用前建议加file_exists和json_last_error()判断
Packagist 官网不提供单个项目依赖总数统计
别被误导：Packagist.org 的页面（如 https://www.php.cn/link/6daab15a4f57549b7f236d7f0cfca3c8）只显示该包自身的下载量、依赖它的其他包数（“Used by”）、以及它声明的 require 列表 —— 它**不记录也不展示任何下游项目最终安装了多少个包**。
也就是说，没有 API 或网页入口能输入你的 composer.json，返回“你这个项目一共会装 87 个包”。所谓“Packagist 统计信息”，仅限于单个包维度，和你的本地依赖图无关。
- 想看某个包被多少项目 require？查页面右上角 “Used by X packages” 数字（数据有延迟，非实时）
- 想估算自己项目的依赖规模？老实用
composer.lock解析，别试图从 Packagist 反推 - 第三方服务如
packagist.org/stats只公开全局趋势（如每月新增包数），不开放明细接口
真正容易被忽略的是：锁文件中 packages 和 packages-dev 的分离逻辑、replace 字段对依赖图的隐式裁剪、以及 minimum-stability 如何影响最终解析出的包集合——这些都会让“总数”在不同环境下浮动。别只数一次就认为固定了。
