Composer show 命令本身不提供维护活跃度指数，仅解析本地 composer.lock 文件，输出包名、版本及依赖关系，不含更新频率、Star 数、安全响应等健康指标；真正评估需结合 Packagist API 的 time 字段、GitHub 的 pushed_at、abandoned 状态及 PHP 版本兼容性人工交叉验证。
Composer show 命令本身不提供维护活跃度指数
直接运行 composer show 或 composer show --tree 只会列出已安装包的名称、版本和依赖关系，完全不包含任何关于维护状态、更新频率、Star 数或安全响应能力的指标。它本质是本地锁文件（composer.lock）的解析器，不是包健康评估工具。
替代方案：用 composer-unused + packagist.org API 手动交叉验证
真正能反映“维护活跃度”的信号得靠外部数据拼凑——比如最近一次 tag 时间、GitHub 上的 commit 频率、是否仍在支持当前 PHP 版本。可行路径是：
- 用
composer show --format=json导出所有包名和版本，提取name字段（如"monolog/monolog"） - 对每个包，访问 Packagist 的 JSON API：
https://packagist.org/packages/{vendor}/{package}.json（例如https://packagist.org/packages/monolog/monolog.json） - 检查返回 JSON 中的
time（最新 release 时间）、funding（是否有赞助）、source.url（跳转到 GitHub 后再看pushed_at和updated_at） - 注意：Packagist API 有速率限制（10 请求/分钟），批量查需加
sleep(0.1)，否则会返回429 Too Many Requests
快速判断法：只查关键包，优先看三个字段
没必要扫全量依赖。重点关注框架层（如 laravel/framework）、安全组件（如 paragonie/random_compat 已废弃）、序列化库（如 symfony/serializer）这类高风险模块。检查时盯死：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
time字段是否在近 6 个月内 —— 超过一年没发版，大概率已进入维护模式 -
abandoned字段是否为true或指向替代包（如"abandoned": "phpunit/phpunit"） -
type是否为library；若为metapackage或project，通常不直接参与运行，活跃度参考价值低
别信第三方 CLI 工具自动打分
像 composer-health 或 composer-require-checker 这类工具，所谓“活跃度评分”其实是把 stars、forks、last commit 加权平均，权重随意，且无法识别“企业内部 fork 后私有维护”这种真实场景。更危险的是，它们常把 Packagist 的 downloads 当作活跃指标——下载量高 ≠ 维护好，可能是旧项目还在批量安装。
真正有效的判断永远来自具体上下文：你的 PHP 版本是否被支持？该包的 issue 列表里，近 3 个月有没有人报告 CVE 相关问题？它的 CI 是否还跑得通？这些没法一键输出，但必须人工点开看。
