在 Web 前端开发中，文本测量一直是一个容易被忽视却又至关重要的底层能力。当我们需要实现虚拟列表、Masonry 瀑布流布局、Canvas 文本渲染，或者在动态内容加载时防止布局抖动时，往往面临一个两难选择：要么使用 DOM 测量获取精确尺寸（触发昂贵的回流），要么自行估算高度（牺牲准确性）。Pretext 的出现正是为了解决这一工程难题，它提供了一种无需触碰 DOM 即可实现多行文本精确测量的方案。

核心问题：为什么文本测量如此昂贵

浏览器在渲染文本时会创建一个复杂的布局树。当我们调用 getBoundingClientRect()、offsetHeight 或 getComputedStyle() 等 API 时，浏览器被迫立即计算元素的精确几何信息，这个过程称为布局回流（Layout Reflow）。根据 Google 的性能研究，回流是浏览器中最昂贵的操作之一，特别是在复杂的页面中，一次回流可能触发级联效应，导致数十甚至数百毫秒的卡顿。

传统的文本高度测量方案依赖这一机制：我们先将文本放入一个隐藏的 DOM 元素，强制浏览器渲染它，然后读取尺寸。这种方法在单次测量时或许可以接受，但在以下场景中变得不可行：虚拟化列表需要对每一行进行测量；动态文本流需要在用户滚动时实时计算布局；Canvas 或 SVG 渲染根本无法使用 DOM 元素作为测量容器。Pretext 的设计正是为了摆脱这一依赖。

技术实现：利用浏览器字体引擎作为真相来源

Pretext 的核心思路非常巧妙：既然浏览器已经有一个精确的文本测量工具 ——Canvas 的 measureText() API—— 我们为什么不直接使用它？开发者通常认为 Canvas 只能测量单行文本，但 Pretext 将这个能力扩展到了多行场景。

具体实现上，Pretext 分为两个阶段。第一阶段是 prepare()：对输入文本进行预处理，包括 Unicode 规范化、文本分词、应用胶水规则（Glue Rules，处理空白字符的换行行为），并使用 Canvas 测量每个文本片段的宽度。这个过程是一次性的，耗时约 19 毫秒可处理 500 个文本片段。第二阶段是 layout()：基于预处理的测量结果，通过纯算术计算得出给定宽度下的行高和行数，每次调用仅需约 0.09 毫秒。

这种设计将测量成本从 O (n) 降低到 O (1)：一旦文本被预处理，后续的布局计算不再需要访问 DOM 或 Canvas，真正实现了零回流。

API 设计：两种使用模式

Pretext 提供了两套 API 以适应不同场景。第一套用于纯高度计算，适合需要知道容器高度的虚拟化场景：

import { prepare, layout } from '@chenglou/pretext'

const prepared = prepare('AGI 春天到了. بدأت الرحلة 🚀', '16px Inter')
const { height, lineCount } = layout(prepared, textWidth, 20)

这里 prepare() 接受文本和字体字符串（格式与 Canvas API 一致，如 16px Inter），返回一個不透明的处理后对象；layout() 接收这个对象、最大宽度和行高，返回计算出的总高度和行数。整个过程没有任何 DOM 操作。

第二套 API 用于需要手动布局每一行的场景，例如 Canvas 或 SVG 渲染：

import { prepareWithSegments, layoutWithLines } from '@chenglou/pretext'

const prepared = prepareWithSegments('Hello World', '18px "Helvetica Neue"')
const { lines } = layoutWithLines(prepared, 320, 26)

for (let i = 0; i < lines.length; i++) {
  ctx.fillText(lines[i].text, 0, i * 26)
}

layoutWithLines() 返回每一行的详细信息，包括文本内容、精确宽度以及在原始文本中的起始和结束位置。如果只需要遍历行范围而不需要构建完整的行文本，可以使用更低层的 walkLineRanges() API，它仅返回每行的宽度和光标位置，适合需要动态探索最优宽度的场景（如二分查找最合适的容器宽度）。

对于宽度逐行变化的场景（比如文本环绕浮动图片），layoutNextLine() 提供了迭代器式的接口，允许每一行使用不同的最大宽度。

工程实践：何时该考虑使用 Pretext

在实际项目中，Pretext 最适合以下几种场景。首先是高性能虚拟列表：当列表项包含多行文本时，传统的 DOM 测量方式会导致严重的性能问题。Pretext 可以在数据绑定时预先计算每一项的高度，实现真正的 O (1) 项渲染。其次是 Canvas 或 SVG 文本渲染：这类渲染上下文本身不提供布局能力，必须手动计算换行位置，Pretext 提供了开箱即用的解决方案。第三是防止布局抖动：当页面动态加载文本内容时，预先知道文本高度可以避免内容插入导致的滚动位置跳变，这对用户体验有直接影响。第四是复杂的 JS 驱动的布局实现：如自定义的 Masonry 布局、Flexbox 的 JavaScript 实现等，需要在布局算法中准确知道元素尺寸。

值得注意的是，Pretext 目前并非万能解决方案。它聚焦于最常用的文本配置：默认的 white-space: normal、word-break: normal、overflow-wrap: break-word 和 line-break: auto。如果你的场景需要特殊的断行行为，可能需要评估兼容性。另外，system-ui 字体在 macOS 上的测量结果不够稳定，建议使用具体的字体名称。

性能基准与选型建议

根据官方基准，对于 500 个文本片段的批处理，prepare() 耗时约 19 毫秒，layout() 仅需 0.09 毫秒。这意味着在需要多次计算同一文本在不同宽度下的布局时，预处理成本可以分摊到极低的单次成本。如果你的应用场景是静态文本的一次性测量，可能不值得引入这个库；但如果是动态内容、频繁重排或 Canvas 渲染，Pretext 提供的精确度和性能优势值得关注。

从工程角度看，Pretext 的价值不仅在于它解决了一个具体问题，更在于它展示了一种思考方式：利用浏览器已有的能力（Canvas 字体引擎）而非对抗它，同时通过预处理将昂贵的操作转化为廉价的查表。在前端性能优化日益重要的今天，这种思路值得借鉴。

资料来源：Pretext GitHub 仓库（https://github.com/chenglou/pretext）