软件包维护检查项目发布的软件包在其注册表上是否处于最新状态、可解析、且未被弃用。注册表维护与 GitHub 活跃度是两回事：一个类库可以在 npm 或 Packagist 上陈旧失修——甚至被明确标记为已废弃——而其仓库仍有提交在进行；用户安装的是软件包，而不是仓库。
- 类别：可持续性与治理（类别内占 20%）
- 在总指数中的权重：4.8%
- 指标键名：
package_maintenance - 适用范围：发布至少一个软件包的仓库；否则为
null
数值如何计算
| 组成部分 | 权重 | 判定标准 |
|---|---|---|
| 已发布且可解析 | 25 | 该仓库至少有一个软件包可在其注册表上解析 |
| 发布时效 | 35 | 最近一次发布 ≤180 天 → 35 分，≤365 天 → 26 分，≤730 天 → 14 分，更久 → 4 分 |
| 版本历史 | 20 | 已发布版本 ≥5 个 → 20 分，≥2 个 → 12 分，否则 4 分 |
| 未被弃用 | 20 | 最新版本被弃用（npm）、废弃（Packagist）或撤回 → 0 分；否则 20 分 |
各组成部分为何重要
- 可解析是底线：软件包能从用户实际会使用的注册表安装。
- 发布时效捕捉一种无声的失败：修复合入了仓库却从未发布——注册表上的副本悄然老化，而仓库看起来仍然活跃。
- 版本历史区分持续维护的发布线与一次性发布。
- 弃用状态是注册表自身最强的信号，由维护者亲自设置；最新版本被弃用会使该组成部分直接归零。
如何解读结果
- 与发布纪律交叉解读：GitHub 发布与注册表发布通常同步推进，二者出现分歧本身就具有参考价值。
- 只有注册表元数据可验证地指向受检仓库的软件包才会被计入——匹配规则参见受支持的生态系统。
- 不发布软件包的仓库在此项为
null，其类别权重重新归一化——绝不会因为项目是应用程序而受到惩罚。
提升数值
- 将向注册表发布纳入发布流程本身，而不是事后补做。
- 对持续维护的软件包至少保持每年一次的发布节奏——哪怕一个补丁版本也能恢复发布时效。
- 绝不让被弃用或被撤回的版本停留在最新位置；应发布后继版本或清除该标记。