composer show 不显示 github 星数，因 packagist api 不返回 stargazers_count 字段；星数需手动访问 source 链接（去 .git 后缀）查看，且仅限 github 仓库；非 github 源或空 source 则无意义。
composer show 本身不显示 GitHub 星数
直接运行 composer show monolog/monolog 或加任何参数（如 --all、--verbose）都不会输出星数——Packagist API 根本不返回 stargazers_count 字段，Composer 也不做额外抓取。
你看到的 source 行（例如 source : https://github.com/Seldaek/monolog.git）才是关键跳板，不是终点。
常见错误是以为 composer show --show-links 会带出 star 数，它只吐出维护者手动填的 homepage/source/dist 链接，且可能为空、指向 GitLab、甚至只是 packagist.org 页面。
- 若
source是 GitHub 地址，去掉.git后缀，粘贴到浏览器即可看到实时 star 数 - 若
source为空或为https://gitlab.com/xxx/yyy，GitHub 星数无意义，别硬凑 - 若只有
homepage（如https://laravel.com），需人工确认是否跳转到 GitHub，很多官网根本不关联仓库
用 Packagist API 查更新时间，不是 composer show 的事
composer show 输出里的 versions 列表不带时间戳，它只告诉你有哪些版本可用，不告诉你哪个版本哪天发布。想查 v3.5.0 是 2024-03-15 还是 2025-11-02 发的，必须绕过 Composer，直连 Packagist API：
curl -s "https://packagist.org/packages/monolog/monolog.json" | jq '.package.versions."3.5.0".time'
注意：time 字段是 Packagist 接收该版本元数据的时间，一般比 GitHub tag 推送晚几秒到几分钟，但足够用于判断活跃度。
- 响应是 ISO8601 UTC 时间字符串（如
"2024-03-15T12:47:22+00:00"），不是本地时间 - API 不保证所有版本都有
time，特别是老包或手工同步的 dist 包 - 别依赖
composer.lock里的time字段——那是你本地执行composer update的时间，和作者发布无关
更新频率得看历史版本间隔，不是单次时间点
单看最新版发布时间容易误判。一个包可能刚发了 v4.0.0，但之前两年没动静；也可能每周都推小版本。真要评估维护节奏，得算最近 3–5 次发布的间隔：
从 Packagist API 响应中提取所有版本的 time，按时间倒序排，取前几个计算天数差。例如：
curl -s "https://packagist.org/packages/guzzlehttp/guzzle.json" | \ jq -r '.package.versions | to_entries[] | select(.value.time) | "\(.value.time) \(.key)"' | \ sort -r | head -5
输出类似：
2025-12-03T14:22:11+00:00 7.9.2 2025-09-18T09:33:44+00:00 7.9.1 2025-07-22T11:15:03+00:00 7.9.0 2025-05-14T16:48:22+00:00 7.8.1 2025-03-26T10:02:55+00:00 7.8.0
- 间隔集中在 2–3 个月，说明有规律维护；若最新两个版本隔了 400 天，就得警惕
- 注意 pre-release 版本（如
8.0.0-beta1）的time可能早于正式版，别混进主干节奏统计 - 有些包用
dev-main当主力分支，它的time更新频繁，但不等于稳定版发布频率
GitHub Pulse 和 contributors 图比 star 数更反映真实活跃度
Star 数容易被刷、被收藏却不使用；而 GitHub 的 /pulse 和 /graphs/contributors 是行为证据：
把 source URL 中的 .git 去掉，加上 /pulse（如 https://github.com/doctrine/orm/pulse），就能看到近 4 周提交热图、PR 合并频率、issue 响应中位数。
- 如果
/pulse显示过去 30 天只有 2 次 commit，且都来自同一人，基本可判定维护乏力 - 打开
/graphs/contributors，若长期只有 1–2 个头像，没有新 contributor 加入，生态扩展性存疑 - 对比
/issues页：open issue 超过 90 天未回复、大量help wanted标签无人跟进，比 star 数下降更危险
真正难的是 source URL 不规范——有些包在 composer.json 里漏填 source，有些指向私有 GitLab，有些甚至用 Bitbucket；这时候 star 数和 pulse 都查不到，只能靠 Packagist 页面的 Dependents 数和近 30 天下载量（downloads.monthly）交叉验证。
