Composer 脚本无法自动检测包的维护状态，需依赖 Packagist 页面标识、源码仓库活跃度、composer.json 中 PHP 版本兼容性及 API 调用等外部手段综合判断。
Composer 脚本本身不提供维护状态检查能力
Composer 的 scripts 是纯执行钩子，它不会自动分析包的 GitHub stars、提交频率或 Packagist 上的最后更新时间。你想知道一个扩展包是否还在维护，得靠外部工具或手动查证，不是靠 composer install 或自定义脚本就能“检测”出来的。
用 composer show 看基础元数据，但信息有限
composer show vendor/package 能显示版本、描述、源类型（git 还是 dist）、homepage 和 source URL，但不包含“最后提交时间”或“是否归档”。关键点：
- 如果
source是 Git 仓库，homepage或source字段通常指向 GitHub/GitLab 页面，这是你手动判断的第一入口 - 输出里没有
last_updated、commit_count_6m这类字段 —— Composer 不采集也不暴露这些 - 有些包在
description里写 “Abandoned! Use vendor/new-package instead”，这是作者主动标记的，值得留意
真正有用的维护状态线索藏在 Packagist 和源码平台
别指望脚本自动打分，但可以快速定位关键信号：
- Packagist 页面（
https://packagist.org/packages/vendor/package）右上角会明确标出abandoned并推荐替代包 —— 这是最权威的弃用声明 - 点进源码仓库（GitHub），看
Last commit时间、Issues是否长期无人回复、PRs是否被 merge —— 活跃度比“star 数”更真实 - 检查
composer.json中require的 PHP 版本范围：如果还锁在^7.2或没适配^8.2，大概率已停滞 - 运行
composer outdated --direct看是否有长期未升级的次要版本（比如卡在2.3.0，而最新是2.9.1），结合发布日期判断是否掉队
想自动化？得自己调 API，不是 Composer 脚本的事
真要批量查，得绕开 Composer，直接请求外部 API：
- GitHub REST API：
GET /repos/{owner}/{repo}返回pushed_at、updated_at、archived - Packagist API：
https://packagist.org/packages/vendor/package.json包含abandoned字段和time（最后发布时间） - 写个简单 PHP/Python 脚本拉这些数据，再按规则打分（比如
pushed_at ），而不是塞进 <code>composer.json的scripts
硬塞进 Composer script 只会让构建变慢、失败逻辑混乱，而且每次 composer update 都触发 API 请求既没必要也容易被限流。
维护状态不是个布尔值，是多个信号拼起来的判断 —— 别漏掉 README 里那行小字 “This package is no longer maintained.”
