当我们谈论 Web 前端性能优化时，DOM 回流（reflow）往往是性能杀手之一，而在文本布局场景中，获取多行文本的高度更是频繁触发回流的典型操作。传统的实现方式依赖于 getBoundingClientRect、offsetHeight 等 DOM API，这些方法虽然直观，但每次调用都会迫使浏览器重新计算布局，对于需要实时响应文本内容变化的场景（例如虚拟列表、动态高度的消息气泡、自定义 masonry 布局），性能开销不容忽视。Pretext 正是为解决这一痛点而生的纯 JavaScript/TypeScript 库，它通过将文本测量逻辑从 DOM 层抽离出来，用 Canvas 的字体引擎作为 ground truth，实现了既快速又准确的多行文本测量与布局能力。
核心架构：预计算与热路径的分离
Pretext 的设计哲学可以概括为「一次测量，多次复用」。整个库拆分为两个核心阶段：准备阶段（prepare）和布局阶段（layout）。准备阶段调用 prepare() 或 prepareWithSegments()，执行一次性的文本分析工作，包括空白符规范化、文本分段、应用 glue 规则（即断行时的连字符处理规则）、以及使用 Canvas 2D 上下文的 measureText() 方法测量每个分段的宽度。准备完成后，函数会返回一个不透明的结构句柄（opaque handle），其中包含了所有预计算的分段宽度和字素边界信息。这个句柄可以重复用于后续的布局计算，而无需重新访问 DOM 或重新测量字体。
布局阶段则完全是纯算术操作。调用 layout() 或 layoutWithLines() 时，库会根据传入的最大宽度（maxWidth）和行高（lineHeight），在预计算的分段数据上进行遍历和累加，判断每个分段是否超过当前行的可用宽度，从而决定是否需要换行。这个过程不涉及任何 DOM 读取或浏览器布局计算，因此执行速度极快。根据官方提供的基准测试数据，在 500 个文本条目的批次上，prepare() 耗时约 19 毫秒，而 layout() 仅需约 0.09 毫秒 —— 两个数量级的差异充分体现了预计算策略的威力。对于需要响应窗口大小变化或文本内容动态更新的场景，只需在 resize 或文本变化时重新调用 layout()，而无需重新调用 prepare()，这正是 Pretext 性能优势的关键所在。
文本分段与字素边界处理
理解 Pretext 的算法细节，需要从文本分段的粒度说起。库内部并不会简单地将文本按字符或单词切割，而是先使用 Unicode 字素簇（grapheme cluster）分割算法将文本拆分为字素序列。字素是用户可感知的最小文本单元，它考虑了组合字符、表情符号等复杂情况 —— 例如带重音符号的字母「é」在某些编码下是单个字符，但在视觉上是一个字素，而「👨👩👧👦」这个家庭表情符号实际上由多个 Unicode 码点组成，但在用户看来是一个完整的表情。Pretext 正是基于这种字素级别的分割来确保文本测量的视觉准确性。
在字素分割的基础上，Pretext 应用了所谓的「glue」规则。Glue 在文本布局术语中指的是「可插入的空白」，即在断行时可以添加但平时不显示的软空格。典型的场景是英文单词之间的空格 —— 在行末如果单词无法完整放入，浏览器会将空格压缩甚至移除，Pretext 通过在预计算阶段标记哪些位置是「glue」，使得后续的布局计算能够正确处理断行时的空白压缩与换行决策。这种设计借鉴了早期 PDF.js 的流式断行思路，但将其适配到了 Web 环境的 Canvas 测量模型中。
对于双向文本（Bidi），Pretext 也有完整的支持。它能够正确处理阿拉伯语、希伯来语等从右向左写的语言与英语、汉语等从左向右写的语言混合排版的场景，即所谓的「混合 bidi」。库内部虽然没有直接实现完整的 Unicode 双向算法，但通过与 pdf.js 的 bidi 组件协作（在库的架构设计中有所体现），确保了双向文本的视觉顺序与逻辑顺序一致。这是很多简单文本测量库容易忽略的细节，而 Pretext 在这一方面做了充分的考虑。
缓存策略与渲染管线集成
Pretext 内部维护了一个共享的缓存机制，用于存储不同字体和文本配置下的测量结果。当同一个字体样式和文本内容被多次测量时，库会直接从缓存中返回结果，避免重复的 Canvas 调用。这个缓存是模块级别的全局缓存，在应用需要切换到大量不同字体或文本变体时，可能导致缓存占用过多内存。为此，库提供了 clearCache() 方法，开发者可以在合适的时机手动清除缓存，例如在页面大幅切换主题字体时。
在渲染管线层面，Pretext 提供了三个层级的 API 以满足不同的集成需求。最高层级是 prepare() + layout() 的组合，适用于只需要知道段落高度和行数的简单场景，例如虚拟列表中的行高预估。中层级是 prepareWithSegments() + layoutWithLines()，在返回高度和行数的同时，还返回每一行的完整文本内容（lines 数组），适合需要手动绘制到 Canvas 或 SVG 的场景。最低层级是 walkLineRanges() 和 layoutNextLine()，前者提供一个回调函数，每遍历一行时调用一次，传入该行的宽度和起止光标，但不生成行文本字符串，适合需要「投机」测试多个宽度边界（例如二分搜索最优宽度）或需要逐行流式布局的场景；后者则是迭代器风格的 API，每次调用返回一行，允许每一行使用不同的宽度，这在实现文本环绕浮动图像等复杂布局时尤为有用。
对于 Canvas 渲染管线，典型的集成代码非常简洁：首先调用 prepareWithSegments() 预计算文本，然后在循环中调用 layoutNextLine() 逐行获取布局结果，最后使用 Canvas 的 fillText() 方法绘制每一行。对于 SVG 渲染，可以将 layoutWithLines() 返回的行信息转换为 <text> 元素的 <tspan> 子元素，实现多行文本的 SVG 渲染。Pretext 的设计目标之一就是支持 DOM、Canvas、SVG、WebGL 以及未来的服务端渲染，这意味着无论你使用哪种渲染技术，都可以利用同一套文本测量逻辑。
性能参数与工程实践要点
在实际工程中集成 Pretext 时，有几个关键参数需要特别关注。首先是 font 参数的格式，它必须与 CSS 中声明的 font 简写形式完全一致，包括字号、字重、字体样式和字体族，例如 '16px Inter' 或 '18px "Helvetica Neue"'。任何不匹配都会导致测量结果与实际渲染结果产生偏差。其次是 lineHeight 参数，它必须与 CSS 的 line-height 属性同步，因为行高直接影响文本的总高度计算。最后是 maxWidth 参数，这是布局计算的核心输入，决定了文本在何处换行。
关于性能优化，官方给出的建议是「不要对同一文本和配置重复调用 prepare ()」。这是一个常被忽视的误区 —— 有些开发者在每次窗口大小改变时都重新调用 prepare()，结果反而不如只调用 layout() 快。正确的做法是：初始化时调用一次 prepare()，然后在 resize 事件中只调用 layout()，传入新的 maxWidth 即可。如果应用场景确实需要频繁切换不同的文本内容，可以考虑对每种文本内容缓存其 PreparedText 句柄，按需复用。
另一个值得注意的工程实践是关于 system-ui 字体的问题。在 macOS 上，使用 system-ui 作为 font 参数会导致测量结果不准确，这是因为浏览器在渲染 system-ui 时会根据平台选择不同的底层字体，而 Canvas 的 measureText() 所使用的字体渲染路径与 DOM 渲染路径存在细微差异。解决方案很简单：始终使用具体的具名字体（如 -apple-system、BlinkMacSystemFont、Inter 等）而非 system-ui。
适用边界与局限性
尽管 Pretext 在文本测量领域表现出色，但它并非要取代浏览器的完整文本渲染引擎。在当前版本中，库仅支持有限的 CSS 布局语义：默认情况下对应 white-space: normal、word-break: normal、overflow-wrap: break-word 和 line-break: auto。如果你需要支持 white-space: pre-wrap（保留空格和换行符），可以在 prepare() 的选项对象中传入 { whiteSpace: 'pre-wrap' }，此时普通空格、制表符和换行符会被保留而不是折叠，但其他布局规则保持不变。另外，对于极窄的宽度（例如小于单个字符的宽度），文本会在字素边界处被强制断开，这是 overflow-wrap: break-word 行为的体现，也是 Web 布局的默认约束。
综合来看，Pretext 为需要高性能文本布局的 Web 应用提供了一个切实可行的解决方案。无论是实现虚拟滚动列表中的精确行高预估，还是构建自定义的 masonry 布局，亦或是在 Canvas/SVG/WebGL 中绘制动态文本，这个库都能帮助你绕过 DOM 回流的性能陷阱，用可预测的计算成本换取流畅的用户体验。