Dormant at the core: Inactivity, dependence and exit among the most downloaded npm packages

现代软件很少是从零开始构建的。相反，它更像是用预制件组装起来的庞大结构，其中的每一个部件都是由他人编写的一小段代码。在 JavaScript 的世界里，支撑这些部件运行的系统被称为 npm，这是一个数字仓库，开发者通过它下载这些代码包来构建从网站到移动应用的一切。这些部件大多由志愿者在业余时间维护。当一名志愿者停止对某个部件进行维护时，那段代码就会进入休眠状态。它不会立即失效，但会停止接收更新、错误修复或安全补丁。这创造了一种隐藏的风险：如果一个被广泛使用的部件停止了更新，那么依赖于它的成千上万个项目都将面临一个一旦出错便无法修复的组件。问题不仅在于这些部件是否停止了更新，还在于究竟有多少部件处于休眠状态，有多少人在使用它们，以及使用者是否知道应该停止使用它们。

一位名叫 Revanth Krishna Maddula 的研究人员着手调查了该系统中最受欢迎的部件。他研究了近一万六千个每周下载量至少达到一百万次的软件包。这些是 JavaScript 生态系统的核心组件，承载着最大的权重。通过研究这些软件包截至 2026 年 10 月的完整历史，他想观察有多少软件包停止了发布新版本，有多少人在继续使用它们，以及当一个部件陷入沉默时，整个系统是如何反应的。这项研究聚焦于一个特定的“休眠”定义：即在过去两年内未发布过稳定、最终版本的软件包。选择这个时间范围是为了区分那些仅仅是已经完工的部件与那些已经被遗弃的部件。

研究结果表明，休眠现象比许多人预想的要普遍得多。在研究期结束时，近 35% 的这些顶级软件包在两年内没有发布过新版本。这种沉默并不局限于晦涩或极少使用的工具；它甚至触及了系统的核心。在下载量前 100 名的软件包中，26% 是处于休眠状态的。事实上，其中一些沉默的软件包甚至已经超过八年没有更新了。尽管存在这种广泛的不活跃现象，但这种沉默几乎总是没有被打破。当研究人员检查这些软件包附带的公开说明（即 README 文件）时，发现只有大约 3% 的休眠软件包明确表示它们不再进行维护。大多数情况下，代码只是停止了变化，让用户只能去猜测这个项目是已经完工还是已被遗忘。

这种沉默的危险在于，系统的活跃部分与这些休眠部分有着深度的连接。研究通过绘制软件包之间的关系图发现，超过四分之一的活跃维护中的软件包直接依赖于至少一个休眠软件包。其中一些沉默的软件包非常核心，通过依赖链可以追溯到一千多个高流量的软件包。这些沉默的软件包中，有些是微小、简单的工具，可能早在多年前就已完工；但另一些则是构成了大量软件工具链基础的重要模块。问题在于，用户无法轻易分辨出一个工具是已经完工了还是已经被遗弃了，因为系统并没有提供清晰的信号来区分这两者。

当一个依赖项进入休眠时，使用者通常不会迅速做出反应。研究追踪了用户在软件包停止更新后多久会移除该依赖。在两年的时间里，用户仅移除了约 27% 的对休眠软件包的依赖。这一比例仅略高于他们移除对活跃软件包依赖的比例，这表明仅仅是软件包停止更新这一事实，并不足以促使人们采取行动。研究人员测试了不同类型的警告是否会改变这种行为。他们发现，项目文档中的注释对用户是否移除该软件包没有产生可检测到的影响。唯一能可靠地促使用户采取行动的信号，是注册表本身发布的官方弃用通知。当一个休眠软件包被系统正式标记为“已弃用”时，用户移除其依赖的比例达到了 65%。这种出现在开发者安装软件时的官方警告，是唯一成功促使生态系统远离这段沉默代码的机制。

此外，休眠还涉及到一个安全维度。虽然大多数休眠软件包在其最新版本中并没有已知的安全缺陷，但那些带有缺陷的软件包则处于危险境地。研究发现，少部分休眠软件包携带了原维护者无法修复的已知漏洞。由于代码不再更新，这些漏洞无法从顶层进行修补。依赖这些软件包的用户必须要么移除它们，要么用其他工具替换，或者由他们自己来修复这些安全漏洞。这种情况凸显了系统中的一个关键缺口：当一个被广泛使用的部件停止维护时，对其安全性的责任便完全转移到了使用者身上，而使用者往往对此并不知情。

研究结论认为，休眠是软件生态系统中很大一部分部分的常态且无声的状态。如果是一个小型工具已经完工，这并不一定是一种缺陷，但缺乏沟通使得用户无法分辨两者的区别。研究表明，目前的系统过于依赖用户去猜测其工具的状态。管理这种风险最有效的方法是，维护者在停止维护某个软件包时使用官方的弃用机制，并最好指向一个替代品。为了保持生态系统的健康，注册表需要让“休眠”和“弃用”变得更加透明，确保信号能够传达给那些需要在沉默软件包成为问题之前看到它的开发者。