技术深度解析
Readability.js本质上是一个针对DOM的复杂模式匹配引擎。它并不试图理解语义，而是通过一系列评分启发式方法，以统计方式推断网页HTML树中哪个部分最可能包含主要文章内容。整个过程分为几个清晰阶段。
首先，执行准备与清理阶段：移除明显非内容的节点，如`<script>`、`<style>`和SVG元素。同时，对类和ID属性应用一组正向与反向的正则表达式模式（例如，可能正向的：`'article'`、`'content'`；可能负向的：`'comment'`、`'social'`、`'ad'`），对元素进行初步标记。
接下来是核心的评分算法。库会遍历DOM，为每个段落（`<p>`）元素分配内容分数。基础分数仅为1。随后，该分数会沿DOM树向上传播，将子元素的分数累加到其父元素。这一简单机制自然使得包含多个段落的容器元素累积高分。算法随后根据启发式规则调整分数：
- 链接密度惩罚：计算元素内链接文本长度与总文本长度的比率。高链接密度（通常>0.2）表明该元素可能是导航栏或链接列表，而非正文，因此其分数会大幅扣减。
- 格式奖励：包含逗号或大量句号的元素可能获得小幅加分，因为这些是句子的特征。
- 类/ID启发式规则：清理阶段的初步正向/负向标记可在最终分数上进行加减。
评分完成后，Readability将得分最高的元素识别为候选内容容器。随后进行后处理精炼：从该候选元素向上回溯DOM，以找到更合理的根节点（例如，能清晰封装所有高分段落的`<div>`或`<article>`标签）。最后，对输出进行净化处理，移除残留的不必要标签，清理空白字符，并通过搜索常见元标签和结构模式尝试提取标题、作者、发布日期等元数据。
其架构纯粹是基于规则且确定性的。这既是其最大优势，也是弱点。它不需要模型权重、推理服务器，计算资源需求极低——可在浏览器后台标签页中即时运行。其逻辑透明且可调试。然而，其有效性受限于规则中编码的智慧。对于将文章内容分散在50个无段落标签的`<div>`标签中，或在Readability初始解析后通过JavaScript动态加载内容的网站，该库很可能无法准确识别。
性能与基准数据
由于缺乏标准化的网页提取基准，量化Readability的准确性具有挑战性。然而，对比分析通常衡量精确率（提取文本中真实内容的百分比）和召回率（成功提取的真实内容百分比）。与其他方法的简化对比揭示了各自的权衡。
| 提取方法 | 核心方法 | 平均精确率 | 平均召回率 | 执行时间 | 设置复杂度 | 隐私/数据需求 |
|---|---|---|---|---|---|---|
| Mozilla Readability | 启发式DOM评分 | ~85-92% | ~80-88% | < 100ms | 极低（npm安装） | 优秀（客户端） |
| Diffbot API | 计算机视觉 + ML | ~95-99% | ~92-97% | 500-2000ms（含网络） | 低（API密钥） | 差（发送URL至供应商） |
| 自定义Scrapy + 规则 | 站点特定XPath | ~99% | ~99% | 可变 | 极高（每站点） | 优秀 |
| 基于LLM的提取（如GPT-4） | 语义指令 | ~90-98% | ~85-95% | 2000-5000ms | 中等 | 差（发送内容至供应商） |
数据启示：对于标准新闻/博客文章，Readability在速度、简洁性和准确性之间提供了卓越的平衡，在成本和隐私方面优于更复杂的解决方案。其召回率的主要弱点通常源于侧边栏内容或复杂媒体布局的遗漏，而非核心文章文本。对于广泛、无监督的多样化网站爬取，它仍是顶级选择。
关键参与者与案例研究
Readability的影响力远不止于Firefox。其宽松的许可证和独立设计使其成为众多清洁内容提取至关重要的应用领域事实上的开源引擎。
主要实施者：Mozilla Firefox
该库最显著的部署是在Firefox的阅读视图中。此集成为其提供了直接、大规模的测试场，每日数百万的页面加载为迭代改进提供反馈。Firefox团队的维护确保了该库能跟上不断发展的网络标准。
内容聚合与稍后阅读服务
Pocket（由Mozilla拥有）历史上曾使用Readability的某个版本进行解析。虽然其当前技术栈更为复杂，但Readability为其奠定了基石。