行业观察｜Pretext：前端排版的一次“去 DOM 化”尝试，Cheng Lou 想重新定义文本布局

前端世界里，有一个问题看起来很小，却一直很难优雅解决：我怎么在不把文字真正塞进 DOM、也不触发布局回流的前提下，提前知道这段话会占多高、会断成几行、每一行会长什么样？

最近，前 React 核心成员、React Motion 作者、现 Midjourney 工程师 Cheng Lou 开源了一个新项目Pretext，就是冲着这个老问题来的。它不是新的 CSS 框架，也不是富文本编辑器，而是一个更底层的能力：用 JavaScript/TypeScript 在 DOM 之外做多行文本测量与布局。

如果说传统网页文本布局的逻辑大多掌握在浏览器排版引擎手里，那么 Pretext 做的事，可以理解为：把其中一部分“测量和换行”的能力，提取成一个开发者可调用的纯计算过程。

它到底解决了什么问题？

在今天的 Web 开发里，如果你想知道一段文字最终有多高，最常见的办法仍然是老三步：

先把文字渲染进页面，再让浏览器完成布局，最后通过getBoundingClientRect()、offsetHeight之类的 API 去读结果。

问题在于，这套方式虽然直观，但代价不低。因为一旦你频繁插入文本、读取尺寸、再调整布局，就很容易触发浏览器的 reflow。放在少量元素上问题不大，可一旦进入虚拟列表、瀑布流、聊天流、信息卡片墙这些高密度场景，性能和视觉稳定性就会迅速变差。

Pretext 的核心思路，是绕开这条路径。它不依赖“先渲染，再测量”的 DOM 方案，而是基于 Canvas 的measureText()和一套自建的换行逻辑，在 JavaScript 里提前算出结果 。

Pretext 的核心：把文本布局拆成 prepare 和 layout

Pretext 最有代表性的设计，是把文本处理拆成两个阶段。

第一阶段是prepare。
在这个阶段，库会对文本做一次性的准备工作：规范空白字符、做文本分段、应用一些粘连和换行规则，并借助 Canvas 去测量各个片段的宽度，然后把这些信息缓存起来。

第二阶段是layout。
到了这一步，就不再重新测量文本，也不访问 DOM，而是直接基于前面缓存下来的宽度数据，做纯计算式的换行和高度推导。换句话说，prepare 像预处理，layout 才是高频热路径。

这也是它性能上最关键的地方。项目仓库给出的一个基准快照显示：在一组 500 段文本的测试里，prepare()大约需要 19ms，而layout()只需要约 0.09ms 。
这意味着如果只是容器宽度变化、窗口 resize、卡片重新排布，理论上你只需要重复执行layout()，而不必重复做完整测量。

为什么它会让前端工程师兴奋？

因为它碰到的是一个很基础、但影响很大的点：文本尺寸是很多 UI 布局的起点。

比如虚拟列表。过去很多列表要么估高、要么先渲染后修正，因此容易出现滚动跳动和位置漂移。Pretext 的价值在于，它让开发者有机会在文本真正进 DOM 之前，就先把每个 item 的高度算出来，从而更稳定地完成预排版。

再比如聊天场景。对消息气泡、AI 流式输出、逐字增长内容来说，文本长度一直在变化。如果每来一点内容就重新触发 DOM 测量，成本会很高。Pretext 这种“预处理一次，后续高频布局”的模式，会更适合这类实时场景 。

它还有一个更有想象力的方向：手动控制每一行文本。
Pretext 不只是能告诉你“这段话有多高”，它还提供了layoutWithLines()、walkLineRanges()、layoutNextLine()这样的 API，允许你拿到逐行结果，甚至给每一行指定不同的可用宽度。这意味着开发者可以做出更复杂的文字绕排、异形排版、多列布局，甚至让文本围绕图片、曲线或动态元素流动。

从官方演示也能看出，Pretext 想解锁的并不只是“更快测高”，而是把浏览器里原本不太好做的高级文本布局，变成可编程能力。

它和传统排版系统有什么不同？

Pretext 并不是要替代浏览器的完整文本渲染引擎。它目前瞄准的是比较常见的一类文本场景，项目文档明确提到，它主要针对类似下面这组默认行为：

• white-space: normal
• word-break: normal
• overflow-wrap: break-word
• line-break: auto

同时也支持pre-wrap这类保留空格、Tab 和换行的情况。

这点很重要。因为它说明 Pretext 不是“重新发明浏览器的一切文本排版”，而是在最常见、最工程化的文本布局需求里，拿出一套足够快、足够准、足够可控的方案。

换句话说，它更像一个前端基础设施库，而不是一个视觉层组件库。

它为什么对 AI 时代更有吸引力？

Pretext 项目介绍里有一句很值得玩味：它使用浏览器自己的字体引擎作为 ground truth，迭代方式“very AI-friendly” 。

这背后的意思是，Pretext 的输入输出关系非常清晰：
给我一段文本、字体、宽度、行高，我返回高度、行数、每行内容、起止游标。这样的接口对于 AI 代码助手、生成式 UI 系统、自动排版工具来说特别友好，因为它天然适合被程序化调用。

放在今天的产品趋势里看，这件事很有现实意义。无论是 AI 生成页面、自动排版邮件、设计工具中的文本模块，还是游戏 UI、Canvas/SVG 绘制系统，它们都越来越需要一种不依赖真实 DOM、但又足够贴近浏览器文字行为的布局能力。Pretext 恰好卡在这个位置上 。

Pretext 真有“几百倍提升”那么夸张吗？

这里需要稍微冷静一点。

外部媒体很喜欢用“300 倍到 600 倍更快”这样的标题来描述 Pretext。这种说法不能说完全没有依据，但非常依赖测试口径：你比较的是哪一部分流程，测的是一次性准备还是高频重复布局，场景是 10 段文本还是 500 段文本，是否包含真实 DOM 插入与读取成本，这些都会显著影响结果。

从官方资料来看，更稳妥的表述应该是：
Pretext 把昂贵的文本测量工作前置并缓存，把后续高频布局变成纯算术过程，因此在“重复 layout、多次 resize、批量文本预排版”这类场景里，有机会显著快于传统 DOM 测量方案。

所以，与其说它神奇地“全面替代浏览器布局”，不如说它精准击中了一个长期性能痛点。

它可能带来什么行业影响？

如果 Pretext 真的被更多项目采用，它的意义可能不只是一个工具库。

第一，它可能改变大家处理文本布局的习惯。
过去很多前端团队默认接受“文本高度只能靠 DOM 读出来”，而 Pretext 提供了另一种思路：能不能在渲染之前先算？

第二，它可能推动更多“去 DOM 化”的 UI 基础设施。
一旦文本测量可以脱离 DOM，那么基于 Canvas、SVG、WebGL 的界面系统会更容易做；服务端预排版、边缘渲染、跨端统一文本内核这些方向，也会更值得探索 。

第三，它可能反过来刺激浏览器生态。
因为 Pretext 的流行，本质上是在提醒业界：前端开发者其实一直缺少一种无副作用、可预测、排版前可调用的文本测量能力。如果这种需求持续放大，未来浏览器标准和原生 API 是否会补上这一层，值得观察。

结语

Pretext 之所以值得关注，不只是因为它快，而是因为它触碰到了前端里一个非常“底层”的问题：文本布局到底能不能从浏览器黑盒里被部分拿出来，变成开发者自己掌控的计算过程？

Cheng Lou 给出的答案是：可以，而且已经能跑起来了。

对于普通开发者来说，Pretext 可能首先是一个高性能文本测量库；但从更长远看，它也许代表着一种新的前端思路——把原本依赖 DOM 才能知道的布局结果，提前变成可编程、可缓存、可组合的数据。

如果这个方向继续成熟，未来很多看起来“只能靠浏览器现场决定”的排版问题，可能都会被改写。

*本文依据网络搜集数据整理，由AI工具辅助完成
All rights reserved. Copyright © 2026