Composer中文元数据无流行度指标，需用发布活跃度与中文描述可信度加权建模：前者统计90天内版本更新次数，后者通过正则检测汉字及中文关键词映射，得分= log(次数+1)×(可信则1.5否则1.0)。
Composer 中文元数据本身不提供流行度指标，所谓“实时统计模型”必须绕过 Packagist 官方 API 的限制，自行采集、清洗、聚合第三方信号——这不是配置问题，而是工程取舍问题。
Packagist API 不返回下载量，downloads 字段已弃用
Packagist v2 API（https://packagist.org/packages/{vendor}/{package}.json）返回的 JSON 中，downloads 字段自 2022 年起固定为 null，且官方明确表示不再维护下载统计。试图依赖该字段会得到空值或 404。
- 真实可用的公开信号只有：
favers_count（GitHub stars）、github_stars（若镜像同步）、abandoned状态、time（最新发布日期） - 历史下载数据仅可通过 Packagist 的每日快照（
https://packagist.org/downloads/）获取 CSV，但延迟 3–7 天，且不含中文元数据维度 - 若强行用
composer show --all或composer depends推导“被依赖数”，结果严重失真：本地锁文件 ≠ 全网使用，且无法区分 dev-only 依赖
中文元数据需从 composer.json 的 description 和 keywords 提取，但无标准化字段
PHP 社区没有强制要求描述语言，description 可能是英文、中文、混合或空字符串；keywords 更常为空或仅含英文术语。不能靠 mb_detect_encoding() 简单判断——UTF-8 编码的英文文本也会被误判为中文。
- 推荐做法：用
preg_match('/[\x{4e00}-\x{9fff}]/u', $description)检测汉字，比编码检测可靠 -
keywords需额外映射词典（如['laravel' => '拉勒维尔', 'cache' => '缓存']），否则中文关键词几乎不存在 - 注意：Packagist 索引时会 strip HTML、trim whitespace，
description实际入库值可能与源composer.json不同
实时性本质是伪命题：最短可行更新周期为 24 小时
所谓“实时”在 Packagist 生态中不可行。所有合法采集方式都受限于：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
立即学习“PHP免费学习笔记（深入）”；
- 官方 rate limit：未认证请求限 60 次/小时，认证后 1200 次/小时 —— 扫描全量包（超 30 万）需至少 25 小时
- GitHub API 有更严 rate limit（5000 token/h），且 stars 数变更不触发 webhook，只能轮询
- 中文包占比不足 0.3%，盲目全量扫描性价比极低；应优先监听
php-zh、laravel-china等组织下新发布事件
真正可落地的轻量模型：基于发布活跃度 + 中文描述可信度加权
放弃“下载量”，转而用两个强相关、易采集、难伪造的代理指标：
-
发布活跃度：过去 90 天内
time字段更新次数（需解析versions数组，排除dev-分支） -
中文描述可信度：满足
preg_match('/[\x{4e00}-\x{9fff}]{5,}/u', $description)且keywords含至少 1 个中文映射词 - 最终得分 =
log(发布次数 + 1) * (中文描述可信度 ? 1.5 : 1.0)，避免小数点后三位的虚假精度
这个模型跑一次全量只需 12 分钟（并发 20 请求 + 本地缓存），结果足够支撑“哪些中文生态库正在活跃演进”的判断——但别把它当下载排行榜用。
