composer元数据无“活跃度”字段，需对接github/gitlab、packagist下载趋势、中文社区三类外部数据源，经归一化、时间衰减和权重校准后计算动态指数，优先实现单库诊断再扩展。
Composer中文元数据里根本没有“活跃度”字段
Composer官方的packagist.org API 和 composer.json 规范里，从不定义“活跃度”——它只提供name、description、require、time（最新 release 时间）、downloads（总下载量）等基础字段。所谓“中文元数据”，也只是指description或keywords含中文，或homepage指向中文文档页，但这些字段本身不携带时间序列或行为信号。
想靠读取composer.json或调用 Packagist API 直接拿到“活跃度指数”，结果只能是空值或误判。
真正可采集的活跃信号只有这三类来源
必须跳出 Composer 本身，对接外部可观测数据源。最稳定、可批量获取的有：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
GitHub/GitLab 仓库 API：看
pushed_at、updated_at、近 30 天commits数、open_issues、forks_count -
Packagist 下载趋势：用
/packages/{vendor}/{package}/stats接口拉取近 30/90 天日下载量，计算环比增长率而非总量 -
中文社区痕迹：不是搜“中文”，而是查是否在
php.net手册页被引用、是否出现在laravel-china.org或learnku.com热门帖中、README.md是否含中文且更新于近 6 个月内
动态指数不能只加权求和，得做归一与衰减
直接把 GitHub stars、下载量、issue 数相加毫无意义——量纲不同、增长曲线不同。必须分步处理：
- 对每个信号单独做
min-max归一（例如：近 30 天 commit 数在同类库中排前 10%，就给 0.9 分） - 引入时间衰减因子：30 天前的 commit 权重为 0.5，60 天前为 0.2，超过 90 天不计入
- 中文相关项（如中文 README 更新、中文社区提及）设为布尔开关+权重修正项，不参与连续归一，避免稀疏数据主导结果
- 最终公式形如：
index = 0.4×github_score + 0.35×download_growth + 0.15×community_zh + 0.1×fork_ratio，系数需按领域校准（如框架类项目 download 权重应高于工具类）
别硬套“指数”概念，先跑通单库诊断再扩展
一开始就想建全网 PHP 库活跃度大盘，大概率卡在数据源限频或结构不一致上。更务实的做法是：
- 写一个命令行工具，输入单个
vendor/package，输出它的各维度原始值+归一后得分+衰减说明（例如：“commit 活跃度 0.82（基于近 30 天 17 次提交，衰减后等效 14.2）”） - 用
composer show --all导出当前项目依赖树，批量喂给该工具，生成本地依赖健康快照 - 只当某库连续 2 次扫描
pushed_at超 180 天未变，且downloads月环比下降 >40%，才标记为“疑似停滞”，而不是给它打个 23.7 的假指数
真正的难点不在算法，而在持续同步 GitHub token 权限、Packagist stats 接口变更、中文社区站点反爬策略——这些比归一公式琐碎得多。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
