快速摘要： Pretext 是一个纯 JavaScript/TypeScript 编写的文本测量与布局引擎，它完全绕过了浏览器的 DOM 回流机制，通过 Canvas API 进行一次性文本宽度采集，之后所有布局计算都是纯粹的算术运算——零 DOM 读写、零回流开销。 官方基准测试显示，在热路径（hot path）上，500 段文本的布局计算仅需约 0.09ms，相较于传统 getBoundingClientRect() 方式提升了约 300～600 倍。该项目由 React 核心贡献者、ReasonML/ReScript 创建者 Cheng Lou 开发，发布短短数天便在 GitHub 上收获了超过万颗 Star。如果你正在做虚拟滚动、聊天界面、编辑器、复杂排版等需要频繁测量文本尺寸的场景，这篇文章会帮你彻底搞清楚 Pretext 的原理、用法和实战价值。往下看，莫潇羽@源码七号站 会为你做更详细的拆解。
一、为什么我们需要关注这个项目？
做过前端的同学应该都有体会：文本测量在浏览器里一直是件挺"重"的事情。
举一个最常见的场景——你有一个聊天界面，里面有几千条消息，每条消息的高度不一样，你需要做虚拟滚动。虚拟滚动的核心前提是什么？你得提前知道每条消息渲染后会有多高。传统的做法是把文本塞进一个隐藏的 DOM 节点里，然后用 getBoundingClientRect() 或者 offsetHeight 来读取它的高度。
这看起来很直觉，但问题出在——每次调用这些属性或方法时，浏览器都可能被迫执行一次同步的布局回流（reflow）。布局回流意味着浏览器需要重新计算受影响元素的位置和尺寸，对于复杂页面来说，这个过程开销极大。Paul Irish 曾经整理过一份详尽的清单，列出了所有会触发强制回流的 JavaScript API，getBoundingClientRect()、offsetHeight、scrollHeight 等等都赫然在列。
更糟糕的是，当你的代码在一个循环里交替进行 DOM 写入和读取时，就会造成所谓的"布局抖动"（Layout Thrashing）——浏览器被迫反复回流，主线程被严重阻塞。在大规模 UI 场景下（比如成千上万条消息、瀑布流、Masonry 布局），这种操作足以让页面卡死。
这就是 Pretext 要解决的根本问题。
莫潇羽在实际项目中遇到过类似的困境——当源码七号站（www.fuyuan7.com）需要展示大量动态内容时，DOM 测量的开销曾经是一个实打实的性能瓶颈。所以当 Pretext 出现时，我第一时间就注意到了它，也花了不少功夫去研究它的原理和代码。下面的内容，就是我整理后的深度分析。
二、Pretext 是什么？
简单来说，Pretext 是一个纯 JS/TS 编写的多行文本测量与布局库。它的核心能力是：让你在不接触 DOM 的情况下，精确计算出一段文本在指定宽度和行高下会占据多少空间（高度、行数），以及每一行的具体内容和宽度。
它的体积很小，约 15KB，没有任何外部依赖，采用 MIT 开源协议发布。
项目地址：https://github.com/chenglou/pretext
在线演示：https://chenglou.me/pretext
作者是谁？
Pretext 的作者是 Cheng Lou（程楼），如果你对前端生态有一定了解，大概率听过他的名字。他曾在 Meta（原 Facebook）参与过 React 的早期核心开发，后来主导了 ReasonML 的设计（ReasonML 后来演进为 ReScript），同时开发了在 React 社区广为人知的动画库 react-motion（GitHub 超过 21000 Star）。他还参与过 Messenger 的前端架构工作。目前，他在 Midjourney 负责整个前端 UI 技术栈的构建。
这样一份履历意味着什么？意味着他在大规模、高性能的 Web UI 场景中有极其丰富的实战经验。当这样一个人说"浏览器的 DOM 文本测量方式已经不够用了"的时候，是值得认真听一听的。
设计渊源
Pretext 的设计思路并非凭空出现。早在十年前，React 团队的另一位核心成员 Sebastian Markbåge 就做过一个叫 text-layout 的实验性项目。那个项目的核心设想是：用 Canvas 的 measureText 进行文本字形度量，用 pdf.js 的 bidi 算法处理双向文本，通过流式行断裂来完成排版。text-layout 项目目前已归档，其仓库的 README 中写道，这些想法已经演化为 Pretext。
Pretext 在 text-layout 的基础上做了大幅度的工程化推进：完整的国际化支持（涵盖中日韩、阿拉伯语 RTL、Emoji 混排等）、跨浏览器差异处理、性能优化，以及一套易于使用的生产级 API。
三、核心原理：它是怎么做到不碰 DOM 就能精确测量的？
这是整篇文章最关键的部分。莫潇羽@源码七号站 在研读了 Pretext 的源码和官方研究文档（RESEARCH.md）之后，把它的核心原理拆解如下。
3.1 传统 DOM 测量的问题在哪？
要理解 Pretext 为什么厉害，得先搞清楚传统方案到底差在哪里。
当你在 JavaScript 中调用 element.getBoundingClientRect() 时，浏览器内部会经历这样一个过程：
首先，浏览器检查当前的布局树（Layout Tree）是否处于"脏"状态——即是否有尚未计算的样式变更或 DOM 修改。如果有（几乎总是有），浏览器必须同步地执行一次完整的布局计算（synchronous layout），把所有受影响的元素的位置和尺寸重新算一遍，然后才能返回你要的那个矩形信息。
这个过程被称为"强制同步回流"（Forced Synchronous Layout / Forced Reflow）。它的开销取决于页面的复杂程度，在移动设备上，一次强制回流可能阻塞主线程 10～100 毫秒。
如果你在一个循环里这样做：
// 这是经典的布局抖动（Layout Thrashing）模式
for (let i = 0; i < items.length; i++) {
items[i].style.height = calculatedHeight + 'px' // 写
const rect = items[i].getBoundingClientRect() // 读 → 触发回流
}每次写-读交替都会触发一次回流，N 个元素就触发 N 次回流——页面直接卡死。
3.2 一个被忽视的细节：浏览器的渲染流水线
要理解 Pretext 的巧妙之处，还需要简单了解一下浏览器的渲染流水线是怎么工作的。当浏览器需要把一个网页呈现在屏幕上时，大致会经过以下几个阶段：首先是解析 HTML 和 CSS，构建 DOM 树和 CSSOM 树；然后将两者合并为渲染树（Render Tree）；接下来进行布局（Layout），计算每个元素在屏幕上的精确位置和尺寸；之后是绘制（Paint），将元素的视觉内容填充为像素；最后是合成（Composite），将不同的绘制层组合在一起显示。
"布局"这个阶段就是我们前面所说的"回流"（reflow）发生的地方。每当你修改了某个元素的尺寸、位置、内容或者任何影响布局的 CSS 属性，浏览器就需要重新执行这个阶段。如果你紧接着通过 JavaScript 读取了某个元素的几何信息（比如调用 getBoundingClientRect()），浏览器就不得不立刻把那些尚未计算的布局变更算完——这就是所谓的"强制同步布局"。
为什么这个操作这么昂贵？因为浏览器的布局算法需要遍历渲染树中受影响的节点，对它们的尺寸和位置进行重新计算。在最坏的情况下，一个元素的尺寸变化可能会影响到它的所有兄弟元素和父元素，导致大范围的重新计算。在移动设备上，一次这样的回流可能需要几十毫秒，而流畅的 60fps 动画要求每帧的总预算只有 16.67ms——一次回流就可能吃掉整个帧预算。
更让人头疼的是，这些 API 的性能开销是隐性的。代码层面看起来只是调用了一个获取高度的方法，似乎无害，但浏览器内部却可能在做大量的计算工作。Paul Irish 整理的那份"触发布局回流的 API 清单"（What forces layout/reflow）是前端性能优化领域非常重要的参考资料，建议所有做性能优化的同学都仔细读一遍。
了解了这些背景之后，我们就能更好地理解 Pretext 的设计为什么值得关注了。
3.3 Pretext 的关键洞察
Pretext 的核心洞察在于一个常常被忽视的事实：浏览器 Canvas 的 measureText() 方法所使用的字体引擎，和 DOM 渲染使用的是同一个字体引擎——但 measureText() 完全不经过 DOM 布局流水线。
也就是说，你可以通过 Canvas 获取到与 DOM 渲染完全一致（或足够接近）的字体度量信息，而完全不触发任何回流。没有回流，就没有主线程阻塞，就没有性能惩罚。
这是 Pretext 整个架构的基石。
3.4 两阶段执行模型
基于上述洞察，Pretext 设计了一个精巧的两阶段执行模型：
第一阶段：prepare（冷路径）
prepare() 是一次性的"重活儿"。它接收原始文本和字体信息，然后依次执行以下步骤：
- 空白字符归一化。根据 CSS 的
white-space规则（默认normal，也支持pre-wrap），将连续空格折叠、处理制表符和换行符。举个例子，在normal模式下，文本中的连续空格"hello world"会被归一化为"hello world"，换行符会被视为普通空格处理。而在pre-wrap模式下，这些空白字符都会被原样保留，就像<textarea>中的行为一样。 - 文本分词。使用浏览器内置的
Intl.SegmenterAPI 按照 locale 规则将文本切分为词段（segments）。这是浏览器原生提供的、基于 Unicode 标准的分词器，能正确处理中日韩文字、阿拉伯语、泰语等不同语言的分词边界。对于中文来说，Intl.Segmenter会在合适的位置进行分词——中文每个字符通常都是一个合法的断行点，但标点符号有特殊的行首禁止和行尾禁止规则。 - 粘连规则（Glue Rules）处理。这一步决定了哪些词段之间可以断行、哪些不能。Pretext 内部至少区分了五种断行类型：普通文本、可折叠空格、不可断粘连（如不可断空格 NBSP 和 Word Joiner WJ）、零宽断行机会（Zero-Width Break Opportunity），以及软连字符（Soft Hyphen）。这些规则确保了断行行为与浏览器原生的 CSS 断行行为尽可能一致。
- Canvas 度量。在一个 OffscreenCanvas（或普通 Canvas）上，将字体设置为用户指定的 CSS font 字符串，然后逐段调用
measureText()测量每个文本片段的像素宽度，并将结果缓存到一个内部的段度量缓存（segment metrics cache）中。这个缓存的设计经过了多轮迭代——根据研究文档的记录，缓存最初只存储宽度数值，后来扩展为存储更丰富的每段度量信息，并采用惰性计算策略来推导更昂贵的派生数据。
整个 prepare() 过程的输出是一个不透明的句柄（opaque handle），内部包含了所有经过预处理和缓存的度量数据。
根据官方基准测试，500 段不同文本的批量 prepare() 耗时约 17～19ms。这个开销只需要付出一次。
第二阶段：layout（热路径）
layout() 是真正的高频操作——每次容器宽度变化（比如窗口 resize）时你都会调用它。
但关键在于：layout() 内部不做任何 DOM 操作、不做任何 Canvas 调用、不做任何字符串分配。它只是对 prepare() 阶段缓存好的宽度数值进行纯粹的算术运算——累加段宽度、判断是否超过行宽上限、计算断行位置、统计总行数和总高度。
具体来说，layout() 的内部逻辑大致是这样的：从第一个文本段开始，逐段累加宽度。当累加宽度超过指定的行宽上限时，回退到上一个合法的断行点，将该点之前的所有段计为一行，然后从断行点之后重新开始累加。如此循环直到所有文本段都被分配到行中。最终的高度就是行数乘以行高。
这个过程的计算复杂度与文本中的段数成线性关系，而且每一步都只涉及简单的数值比较和加法运算——没有对象分配、没有垃圾回收压力、没有 I/O 操作。这就是为什么它能如此之快。
从 Pretext 的源码来看，layout() 和高级布局 API 共享的行遍历核心逻辑位于 src/line-break.ts 中。这个模块被设计为尽可能高效——避免不必要的内存分配，通过游标（cursor）机制在段流中导航，而不是生成中间数据结构。
这就是为什么它可以如此之快：500 段文本的 layout() 仅需约 0.09ms。
用一个形象的比喻来说：prepare() 就像你提前把一条路上所有路段的长度都丈量好了，记在一个小本子上。之后无论你想算从 A 到 B 有多远，只需要翻本子做加法就行了——不需要每次都扛着卷尺去实地丈量。
3.5 这个"500 倍"怎么理解？
关于性能数字，需要做一个客观的说明。Cheng Lou 本人也坦言，这个对比"不太公平"。
所谓的 300到600 倍提升，比较的是 layout() 的热路径（约 0.09ms 处理 500 段文本）与传统 DOM 测量（约 1530ms 处理同样数量的文本，同时触发 500 次回流）之间的差距。这个对比没有算入 prepare() 的一次性开销（约 17～19ms）。
但这正是两阶段模型的精妙之处：prepare() 只做一次，layout() 可以做无数次。在虚拟滚动、窗口 resize、容器宽度动态变化等场景下，layout() 被反复调用的频率远高于 prepare()，因此热路径的性能才是真正决定用户体验的因素。
对于普通的博客或企业官网来说，这种级别的性能差异确实不太明显——因为浏览器的回流在简单页面上并不频繁。但对于聊天应用、协作编辑器、虚拟化列表、动态排版工具等高频交互场景来说，这种差异足以决定界面是流畅还是卡顿。
四、源码结构一览
莫潇羽翻阅了 Pretext 的仓库结构，以下是核心源码的组成部分（信息整理自项目的 AGENTS.md 和 CLAUDE.md），帮助有兴趣深入研究的朋友建立一个整体认知：
src/analysis.ts— 负责归一化、分词、粘连规则应用，以及prepare()的整个文本分析阶段src/measurement.ts— Canvas 度量运行时，包括段度量缓存、Emoji 宽度修正、以及不同浏览器引擎的 profile shimsrc/line-break.ts— 内部行遍历核心逻辑，被高级布局 API 和热路径行计数器共用src/bidi.ts— 简化的双向文本元数据辅助模块，服务于prepareWithSegments()路径src/layout.ts— 布局计算的主模块
从源码的 measurement.ts 中可以看到，Pretext 在初始化测量上下文时，优先使用 OffscreenCanvas（如果环境支持），否则回退到普通的 document.createElement('canvas')。OffscreenCanvas 的好处是它可以在 Web Worker 中运行，未来有可能将 prepare() 阶段完全移到后台线程执行。
另一个值得注意的细节是 Emoji 宽度修正机制。在 macOS 上，Chrome 和 Firefox 在 Canvas 中测量 Emoji 的宽度有时会比 DOM 中的实际渲染宽度更大（尤其在较小字号时），而 Safari 则没有这个差异。Pretext 内置了一套引擎 profile 检测机制来处理这类跨浏览器 quirks。
五、API 详解与实战用法
Pretext 提供了两大类 API，分别面向简单场景和高级场景。下面莫潇羽@源码七号站结合具体代码来逐一讲解。
5.1 基础 API：测量段落高度
这是最常用的场景。你只需要两个函数：prepare() 和 layout()。
安装：
npm install @chenglou/pretext最简单的用法：
import { prepare, layout } from '@chenglou/pretext'
// 第一步：prepare —— 一次性预处理
const prepared = prepare(
'这是一段需要测量的中文文本，夹杂English和Emoji🚀',
'16px Inter' // CSS font 字符串
)
// 第二步：layout —— 纯算术计算，可反复调用
const { height, lineCount } = layout(
prepared, // prepare 返回的句柄
300, // 容器宽度（像素）
20 // 行高（像素）
)
console.log(`文本高度: ${height}px, 共 ${lineCount} 行`)这段代码没有创建任何 DOM 节点，没有触发任何回流，但你得到了精确的高度和行数信息。
关于 font 参数： 第二个参数是一个标准的 CSS font shorthand 字符串，比如 '16px Inter'、'bold 14px "Helvetica Neue"'、'18px "PingFang SC"' 等。需要注意的一点是，Pretext 官方文档提到 不要使用 system-ui 作为字体名——因为在 macOS 上，system-ui 在小字号和大字号时会映射到不同的字体变体（SF Pro Text vs SF Pro Display），而 Canvas 和 DOM 切换的阈值不同，这会导致测量不准确。始终使用具名字体。
在 resize 时的用法：
// prepare 只做一次
const prepared = prepare(longText, '16px Inter')
// resize 时只需重新 layout
window.addEventListener('resize', () => {
const containerWidth = container.clientWidth
const { height } = layout(prepared, containerWidth, 20)
// 直接使用新的高度信息
virtualScroller.updateItemHeight(itemId, height)
})每次 resize 触发时，layout() 的执行时间都是亚毫秒级的，完全不会阻塞渲染。
处理 textarea 风格的文本：
默认情况下，Pretext 按照 CSS white-space: normal 的规则处理空白——连续空格会被折叠为一个，换行符被当作普通空格。但如果你需要像 <textarea> 那样保留空格、制表符和换行符，可以传入配置项：
const prepared = prepare(
textareaValue,
'16px Inter',
{ whiteSpace: 'pre-wrap' } // 保留空白和换行
)
const { height } = layout(prepared, textareaWidth, 20)在 pre-wrap 模式下，制表符会按照浏览器默认的 tab-size: 8 来处理。
5.2 高级 API：手动控制每一行的布局
如果你的需求不只是"知道文本多高"，而是需要精确控制每一行的排布——比如让文字环绕图片、实现多栏排版、瀑布流布局等——Pretext 提供了一组更底层的 API。
prepareWithSegments() + layoutWithLines()：获取所有行的信息
import { prepareWithSegments, layoutWithLines } from '@chenglou/pretext'
const prepared = prepareWithSegments(
'这是一段很长的文本，需要分成多行来渲染...',
'18px "Helvetica Neue"'
)
// 获取在 400px 宽度下的所有行
const lines = layoutWithLines(prepared, 400)
// 每一行都有完整的信息
lines.forEach(line => {
console.log(line.text) // 这一行的文本内容
console.log(line.width) // 这一行的实际宽度
console.log(line.start) // 起始游标位置
console.log(line.end) // 结束游标位置
})返回的 LayoutLine 类型结构如下：
type LayoutLine = {
text: string // 该行的完整文本内容
width: number // 该行的实际测量宽度
start: LayoutCursor // 在 prepared segments 中的起始位置
end: LayoutCursor // 在 prepared segments 中的结束位置
}
type LayoutCursor = {
segmentIndex: number // 段索引
graphemeIndex: number // 段内字素索引
}有了行级别的信息，你就可以把文本渲染到 Canvas、SVG 或者任何你想要的渲染目标上。
layoutNextLine()：迭代器风格的逐行布局
这是最灵活的 API。它允许你一行一行地布局，而且每一行可以使用不同的宽度。这意味着你可以实现文字环绕任意形状的障碍物。
import { prepareWithSegments, layoutNextLine } from '@chenglou/pretext'
const prepared = prepareWithSegments(
'很长的文本内容，需要环绕一个图片来排列...',
'18px "Helvetica Neue"'
)
// 用游标追踪当前位置
let cursor = { segmentIndex: 0, graphemeIndex: 0 }
let y = 0
const lineHeight = 26
while (true) {
// 根据 y 坐标动态计算可用宽度
// 如果当前行在图片区域内，可用宽度需要减去图片占用的空间
const availableWidth = y < image.bottom
? columnWidth - image.width
: columnWidth
// 布局当前行
const line = layoutNextLine(prepared, cursor, availableWidth)
if (line === null) break // 文本已全部排完
// 渲染这一行（比如用 Canvas）
ctx.fillText(line.text, 0, y)
// 移动游标到下一行起点
cursor = line.end
y += lineHeight
}上述代码实现了一个基本的文字环绕图片效果，而且完全不涉及 DOM 操作。每一行的宽度可以独立控制，这意味着你可以环绕任意复杂的形状——圆形、多边形、甚至动态移动的物体。
有开发者用这个 API 实现了一条动画龙在文本中穿梭的效果——龙移动时，周围的文字实时环绕重排，全程保持 60fps，因为所有的文本布局计算都在亚毫秒级完成。
walkLineRanges()：轻量遍历行范围
如果你只需要知道每一行的宽度和游标范围，不需要构建实际的文本字符串，可以用这个更轻量的 API：
import { prepare, walkLineRanges } from '@chenglou/pretext'
const prepared = prepare(text, '16px Inter')
// 找到最宽的一行，用于确定最紧凑的容器宽度
let maxWidth = 0
walkLineRanges(prepared, 320, line => {
if (line.width > maxWidth) maxWidth = line.width
})
// maxWidth 就是刚好能容纳所有文本的最小宽度
console.log(`最佳容器宽度: ${maxWidth}px`)这个功能在实现"紧贴内容的气泡框"时特别有用——聊天应用中消息气泡的宽度应该刚好包裹住最长的那一行，不多不少。
5.3 辅助函数
import { clearCache, setLocale } from '@chenglou/pretext'
// 清除内部缓存，释放内存
// 适合在大量文本处理完成后调用
clearCache()
// 设置分词的 locale
// 会影响 Intl.Segmenter 的分词行为
setLocale('zh-CN')clearCache() 清除的是 prepare() 和 prepareWithSegments() 共用的内部度量缓存。在处理完大批量文本后调用它，可以释放不再需要的内存。
六、在不同渲染目标上使用 Pretext
Pretext 本身只负责计算——它告诉你文本的尺寸和断行位置，至于怎么渲染，由你决定。这种设计让它可以服务于多种渲染目标。
6.1 DOM 渲染
最直接的用法是用 Pretext 预计算高度，然后按照计算结果操作 DOM：
// 虚拟滚动场景：预计算所有条目的高度
const heights = messages.map(msg => {
const prepared = prepare(msg.text, '14px Inter')
const { height } = layout(prepared, containerWidth, 20)
return height + padding // 加上内边距
})
// 把高度信息提供给虚拟滚动库
virtualList.setItemHeights(heights)这样你就不需要先把所有消息都挂载到 DOM 上再逐个测量高度了——省去了成千上万次的 DOM 回流操作。
6.2 Canvas 渲染
用 layoutWithLines() 或 layoutNextLine() 获取每一行的文本和位置，直接渲染到 Canvas 上：
const prepared = prepareWithSegments(text, '16px Inter')
const lines = layoutWithLines(prepared, canvasWidth)
const ctx = canvas.getContext('2d')
ctx.font = '16px Inter'
lines.forEach((line, index) => {
ctx.fillText(line.text, 0, index * lineHeight)
})社区中已经有开发者基于这个能力实现了一些令人惊叹的 Canvas 演示——比如用比例字体渲染的 ASCII 艺术动画、流体烟雾效果的字符渲染等，全程保持高帧率运行。
6.3 SVG 渲染
同理，你可以将行级信息映射为 SVG 的 <text> 元素。这对于生成可缩放的矢量文本排版特别有用。
6.4 未来：服务端渲染
Pretext 的测量上下文初始化代码显示，它在没有 DOM 的环境下会尝试使用 OffscreenCanvas。项目仓库中还保留了一个基于 HarfBuzz 的无头后端（headless backend），用于在服务端进行度量探测。这意味着未来的版本有可能支持在 Node.js 环境下进行文本布局计算，进一步扩展使用场景。
七、国际化支持：处理世界上几乎所有的文字
作为莫潇羽@源码七号站的读者，你可能特别关心中文的支持情况。这里可以放心：Pretext 在国际化方面下了很大功夫。
中日韩文字（CJK）
中文、日文、韩文的排版与拉丁文字有很大不同——CJK 文字通常每个字符都可以作为断行点，标点符号有特殊的位置规则（行首禁则、行尾禁则等）。Pretext 通过 Intl.Segmenter 配合自定义规则来处理这些情况。
根据项目的研究文档（RESEARCH.md），中文目前是 CJK 测试语料的主要"金丝雀"，在宋体 SC 和苹方 SC 之间存在一些字体敏感性差异，但在锚定宽度下测试通过。日文有两个长篇测试语料（芥川龙之介的《罗生门》和《蜘蛛之丝》），在锚定宽度下结果清洁。韩文在采样的 Chrome 矩阵中保持精确。
阿拉伯语与双向文本（Bidi）
Pretext 内置了简化的 bidi 元数据辅助模块（src/bidi.ts），用于处理混合了从左到右（LTR）和从右到左（RTL）的文本。你可以在一段文本中同时包含中文、英文和阿拉伯文，Pretext 会正确处理它们的方向性和断行。
根据研究文档，阿拉伯语的支持经历了多轮迭代。因为阿拉伯语有字形连接（shaping）的特性——同一个字母根据在词中的位置不同会呈现不同的形态——这给基于"段宽度求和"的架构带来了特殊挑战。目前的实现在预处理和语料清理后已经达到了较好的精度。
Emoji 混排
Emoji 的处理是另一个容易出问题的地方。不同浏览器在不同字号下对 Emoji 宽度的计算存在差异。Pretext 通过引擎 profile 检测和 Emoji 修正缓存来处理这些不一致性，确保跨浏览器结果的一致性。
其他语言
泰语、高棉语、印地语、希伯来语等都在 Pretext 的测试矩阵中。缅甸语（Myanmar）目前仍是东南亚语言中的主要未解决前沿——在 Chrome 和 Safari 之间存在一些引号/跟随样式类的分歧。
八、跨浏览器差异处理
做过前端兼容性工作的同学都知道，不同浏览器的渲染行为千差万别。Pretext 在这方面投入了大量精力。
项目仓库中维护着三个浏览器的精确度快照文件：accuracy/chrome.json、accuracy/safari.json、accuracy/firefox.json。团队通过自动化的浏览器扫描（bun run accuracy-check）来持续验证 Pretext 在不同浏览器中的预测精度。
一些具体的浏览器差异处理策略：
- macOS 系统字体问题： 前面提到过，macOS 的
system-ui在小字号和大字号时映射到不同的字体变体，而 Canvas 和 DOM 切换的阈值不同。Pretext 的处理策略是建议使用具名字体来规避这个问题。 - Emoji 宽度差异： Chrome 和 Firefox 在 macOS 上可能在 Canvas 中测量出比 DOM 更宽的 Emoji 值，Safari 没有这个问题。Pretext 通过引擎 profile shim 进行修正。
- 行尾公差： 不同浏览器的 CSS 文本布局实现在行尾的处理上可能有微小差异。Pretext 在某些情况下引入了浏览器特定的行适配公差（line-fit tolerance）。
九、实际应用场景
理解了原理和 API 之后，来看看 Pretext 在实际项目中能解决哪些问题。莫潇羽@源码七号站 总结了几个最有价值的应用场景。
9.1 虚拟滚动 / 虚拟化列表
这是 Pretext 最典型的应用场景，值得展开来说一说。
虚拟滚动（Virtual Scrolling）是处理长列表的标准方案。它的核心思想是：只渲染用户当前可见区域内的条目，滚动时动态替换渲染内容。这样即使列表有十万条数据，实际 DOM 中也只有几十个节点。
但虚拟滚动要正常工作，有一个关键前提：你必须知道每一项的高度。因为虚拟滚动组件需要根据所有条目的高度总和来计算总的滚动区域大小，同时根据当前滚动位置来确定哪些条目应该被渲染。
如果所有条目的高度是固定的（比如都是 50px），那很简单。但在实际业务中，条目高度往往是动态的——一条简短的消息可能只有 40px 高，而一条包含多行文本和图片的消息可能有 300px 高。
传统的处理方式通常有这么几种：第一种是给所有条目一个估算的固定高度，滚动时再动态修正——这会导致滚动条长度跳动、滚动位置不准确的问题。第二种是在组件挂载时先把所有条目渲染一遍来获取真实高度——但这样做就失去了虚拟化的意义，初始加载时间会很长。第三种是只渲染可见区域的条目，动态测量高度后再更新——这可能导致可见的布局跳动（CLS），用户体验不佳。
有了 Pretext，这个问题就有了一个优雅的解决方案：在条目挂载到 DOM 之前，通过纯计算的方式预先获取所有条目的精确高度。即使列表有 100,000 个条目，prepare() 的一次性开销也是可接受的（可以在 Web Worker 中异步执行），而后续的 layout() 计算可以在毫秒级完成。
这意味着虚拟滚动组件在初始化时就拥有了完全准确的高度信息——滚动条长度正确、滚动位置精准、没有视觉跳动。这对用户体验的提升是非常显著的。
9.2 聊天界面
聊天界面是另一个非常适合 Pretext 发力的场景，值得仔细说一说。
聊天界面中的消息气泡需要同时做好几件事：首先是确定气泡的高度，这在虚拟滚动场景下至关重要；其次是确定气泡的宽度——好的聊天 UI 中，气泡应该紧贴最长行的宽度，而不是总撑满整个容器，这样视觉上更加紧凑和美观；最后还要处理各种语言混排的情况，比如用户可能在一条消息中同时使用中文、英文和 Emoji。
传统的做法是先把消息文本渲染到一个隐藏的 DOM 节点中，读取它的 scrollWidth 和 scrollHeight，然后把这些尺寸信息应用到实际的气泡元素上。这个过程涉及多次 DOM 操作，而且每条新消息到达时都要重复一遍。如果聊天窗口需要一次性加载数百条历史消息，这个开销就会变得很明显。
用 Pretext 可以完全避开这些 DOM 操作。walkLineRanges() 遍历所有行找到最宽的一行，就得到了气泡的内容宽度；layout() 直接给出总高度。整个过程是纯粹的数学计算，一条消息的测量耗时在微秒级别。这样即使一次性加载一千条历史消息，也不会有任何可感知的延迟。
而且由于 Pretext 对中日韩、阿拉伯语和 Emoji 的全面支持，你不需要为不同语言的消息编写不同的测量逻辑——统一使用同一套 API 就能得到正确的结果。
9.3 自适应文本容器
在日常的前端开发中，有大量场景需要根据文本内容动态调整容器尺寸。
最典型的例子是自动增高的文本输入框（auto-growing textarea）。当用户输入更多文本时，输入框应该自动变高来容纳所有内容，而不是出现滚动条。传统的实现方式通常是在输入事件中读取 scrollHeight，然后将其设置为输入框的高度——这会触发回流。如果用户在快速打字，每次按键都会触发一次回流，在复杂页面上可能导致输入体验卡顿。
用 Pretext 配合 { whiteSpace: 'pre-wrap' } 选项，你可以在每次输入变化时通过纯计算获取文本的预期高度，然后直接设置容器高度，避免了读取 scrollHeight 引发的回流。
类似的场景还有手风琴组件（Accordion）的展开高度预测——在用户点击展开之前就计算好内容区域的精确高度，可以让展开动画更加流畅自然，而不需要先渲染内容再读取高度再做动画。Tooltip 和 Popover 组件也有同样的需求——在定位这些浮层之前，需要知道它们的尺寸才能决定弹出方向和位置。
9.4 防止布局偏移（CLS）
布局偏移（Cumulative Layout Shift）是 Google Core Web Vitals 的关键指标之一。CLS 衡量的是页面在加载和交互过程中视觉元素发生意外位移的程度。当新内容加载后导致已有内容的位置发生跳动时，CLS 分数就会增加，直接影响搜索引擎排名和用户体验。
文本内容的延迟加载是导致 CLS 的常见原因之一。当文本通过异步请求加载后填入容器时，如果容器没有提前预留正确的高度，文本的出现会把后续内容向下推挤，造成明显的视觉跳动。
通过 Pretext 提前计算好文本区域的精确高度，你可以在文本实际加载和渲染之前就为容器设置正确的高度占位。这样文本出现时不会改变容器的尺寸，后续内容的位置也不会发生变化——从源头上消除了文本加载导致的布局偏移问题。对于注重 SEO 和 Core Web Vitals 评分的站点来说，这是一个非常实用的优化手段。
9.5 复杂排版与编辑器
如果你正在构建一个在线文档编辑器、协作工具或者内容管理系统，Pretext 的行级 API 可以帮你实现一些传统 CSS 难以做到（或做起来极其复杂）的排版效果。
多栏文本流（类似杂志的分栏排版）就是一个典型的例子。虽然 CSS 有 column-count 和 column-width 属性，但它们的行为在很多边缘情况下并不理想，而且无法精确控制文本在栏之间的分配方式。用 Pretext
