github每一一库：Pretext —— 当文本布局不再需要 DOM

它到底做了什么

传统方案里，想知道一段文字占几行、有多高，唯一可靠的办法是把它塞进 DOM，调 getBoundingClientRect() 或 offsetHeight，然后浏览器被迫触发 layout reflow——这是浏览器最昂贵的操作之一。在消息列表、虚拟滚动、动态内容流这些场景里，这种开销会成倍累积。

Pretext 的做法是彻底绕开 DOM。它是一个纯 TypeScript 库，gzip 后约 15KB，零依赖，用一个 off-screen canvas 的 measureText API 预先测量文本片段宽度，再通过纯算术模拟浏览器的换行逻辑。换句话说，它把“文本测量”从一次 DOM 操作变成了一次可缓存、可重复调用的纯计算。

项目的核心设计只有两个阶段：prepare() 负责分词、测量和缓存，是昂贵的一次性开销；layout() 负责在给定宽度下计算高度和断行，是廉价的纯算术热路径。官方数据是：prepare() 处理 500 条文本批次约 19ms，而 layout() 的热路径只需要 0.09ms，并且可以无限次重复调用而无需重新测量。有开发者拿整本小说做即时分页对比，Pretext 每次运行 2–3ms，DOM 方案则超过 100ms。

为什么它值得一篇博客

作者背景本身就自带技术叙事。 Cheng Lou 的履历几乎是一条“挑战默认前提”的线索：在 React 核心团队理解 UI 框架的渲染模型，然后用 react-motion 拒绝 CSS 缓动曲线、把动画变成弹簧物理，再用 ReScript 拒绝渐进类型、把 ML 级类型安全带到 Web。Pretext 是同一个模式的第三次延伸：文本测量不应该是 DOM 访问，而应该是纯计算。

数据足够诚实，也足够有冲击力。 项目发布后短短几周 GitHub 星标冲到 49k 左右，MIT 许可。Cheng Lou 自己承认“比传统方式快约 500 倍”的对比可能不公平，但即便按更保守的官方 benchmark，layout() 热路径相对 DOM 测量也有 200 倍以上的量级差异。这种“承认前提、但差异依然巨大”的表述，反而比单纯喊“500 倍”更适合写出一篇有分寸感的技术博客。

真实场景足够具体。 Pretext 不只停留在 benchmark 里。它可以让一个页面同时放下几十万个高度各异的文本框，通过遮挡虚拟化（Occlusion Virtualization）实现 120fps 的丝滑滚动与缩放，可见性判断不需要任何 DOM 尺寸测量，只是一次线性遍历。聊天气泡能随内容自动贴合宽度，多栏响应式杂志排版、可变字体宽度的 ASCII 字符画、自动增高输入框、纯 Canvas 多行文本——这些过去在 CSS 里相当棘手的需求，都变成了可以直接计算的布局问题。

适合放进博客的结构

如果你要把它写成一篇发布用的技术博客，下面这条线会比较顺：

① 从一个所有人都忍过的痛点切入。 不要一上来就介绍库，先讲那个场景：一个消息列表要动态计算每条气泡的高度，你不得不渲染、测量、再调整；虚拟滚动里元素高度不确定，滚动条疯狂跳动。DOM reflow 不是“慢一点”，而是在大量文本元素面前变成结构性瓶颈。

② 介绍 Pretext 的定位。 一句话：无需触碰 DOM 的纯 JS/TS 文本布局引擎，作者 Cheng Lou，MIT 协议，约 15KB gzipped，零依赖。然后用一段话讲清 prepare / layout 的分工，配一张极简的流程图——两阶段、一次测量、多次布局。

③ 把性能数字放在具体操作里。 不要只写“快 200 倍”。写：prepare() 19ms 把一批文本“预处理”完，之后每次窗口宽度变化、容器尺寸调整，layout() 只用 0.09ms 重新算高度。再补一个分页对比：2–3ms vs 100ms 以上。读者立刻能感受到“热路径便宜”意味着什么。

④ 给一两个场景化的概念示例。 Pretext 支持 React、Vue、Svelte、Angular、Solid 以及原生 JS。博客里不需要完整项目，可以描述：在 React 里用 useMemo 包住 prepare，在 ResizeObserver 回调里只调用 layout；或者在 Canvas 渲染管线里，先用 Pretext 算出行高，再决定绘制位置。重点传达“测量与布局解耦”的使用心智。

⑤ 诚实地说清楚它不做什么。 Pretext 不追求完整 CSS 排版，复杂嵌套标记、pre-wrap 等需要显式开启，简单静态文本和已有 CSS 布局能满足的场景并不适合引入它。同时提一句“500 倍”是在特定对比条件下得出的，作者本人也做过澄清。一篇有可信度的博客，恰恰需要这一节。

⑥ 收在“约束是可以被拒绝的”这个点上。 Pretext 的意义不止是一个更快的文本测量库。它示范了一种工程判断：当所有人都接受“要知道文本高度就得读 DOM”时，有人退后一步，把问题重新定义成“文本测量本质上是字体引擎 + 算术”。对于正在面对性能瓶颈、或者正在思考 AI 生成 UI 时代布局基础设施的读者，这个视角比星数更有长期价值。