Composer 本身不提供更新频率统计，需通过 Packagist API 获取各版本 time 字段计算间隔，或结合 GitHub pulse/contributors 图、commits 密度、issues 响应速度及 CHANGELOG 中安全修复与 PHP 版本支持情况综合判断维护活跃度。
Composer 包的更新频率怎么看
Composer 本身不提供包的更新频率统计功能，composer show 或 composer outdated 只能查当前版本和可用更新，不记录历史发布节奏。真要看更新频率，得靠 Packagist 的公开 API 和第三方数据源。
最直接的方式是访问包在 Packagist 上的页面（比如 https://packagist.org/packages/vlucas/phpdotenv），滚动到底部看「Releases」列表——发布时间、Tag 名、是否带 pre-release 标记都一目了然。注意：Packagist 页面显示的是 Git Tag 时间，不是 Packagist 同步时间，一般延迟很小。
如果要批量或自动化分析，可用 Packagist API：https://packagist.org/packages/{vendor}/{package}.json，响应里的 packages 字段下每个版本对象含 time 字段，按该字段排序就能算出最近 3 次发布的间隔天数。
用 GitHub 数据辅助判断维护活跃度
很多 Composer 包的源码托管在 GitHub，而 GitHub 的活动指标比 Packagist 更丰富。重点看三个地方：
-
commits的时间密度（不是总数）：近 6 个月内是否有每周级提交？还是集中在某次大版本后长期静默？ -
issues和pull requests的响应速度：Open 的 issue 平均多久被回复？有没有大量 stale issue（>90 天未处理）？ -
releases页是否与 Packagist 同步：有些包会打 Tag 但忘了composer publish，导致 Packagist 不更新。
小技巧：GitHub URL 加上 /pulse（如 https://github.com/guzzle/guzzle/pulse）可快速查看近 4 周的贡献热图；加 /graphs/contributors 能识别是否只有 1–2 人长期维护。
composer show -s 输出里藏着关键线索
composer show -s vendor/package（-s 表示显示源信息）会打印包的 source 和 dist 地址，其中 source 通常是 Git 仓库地址。这个地址必须能公开访问，否则无法验证维护状态。
常见陷阱：
- 地址是私有 GitLab/GitHub Enterprise 链接（如
git@gitlab.example.com:foo/bar.git）→ 说明你本地能装，但外人无法审计，维护透明度低。 -
source显示为type: svn或hg→ 极少见，但意味着工具链老旧，CI/CD 支持可能弱。 -
dist的url指向一个已失效的 zip 链接（404）→ 包可能已被弃用，Packagist 缓存还在。
别只盯“最后更新时间”，要看更新性质
一个包上周刚发了 v3.2.1，不等于它健康。打开它的 CHANGELOG 或 Release Note，重点扫三类内容：
- 是否修复
security相关 issue？高频安全更新通常代表积极维护。 - 是否有
deprecate提示？连续两版加新 deprecation 而不提供迁移路径，往往是走向废弃的信号。 - 是否支持新版 PHP？比如仍要求
"php": "^7.2"且无 issue 讨论升级计划，基本可判定维护滞后。
另外，composer depends vendor/package 能反查谁在依赖它——如果 Laravel、Symfony 官方组件都依赖它，大概率不会突然停更；反之，若只有几个小众项目引用，就得自己多盯。
真正难判断的，是那种每年发 1–2 个 patch 版本、没安全问题、也没新功能的包：它可能稳定到无需更新，也可能只是“活着但没人管”。这时候，翻它的 CI 状态（.github/workflows）、PHPStan/ Psalm 配置是否存在，比发布时间更有说服力。
