Pretext 如何颠覆前端文本布局Pretext 完全指南：重新定义 Web 文本布局，性能提升 300 倍，彻底告别

Pretext 完全指南：高性能文本测量与布局的终极方案

作者：Cheng Lou（前 React Core 成员）
项目地址：github.com/chenglou/pr…
关键词：文本测量、避免重排、Knuth-Plass、Shrinkwrap、多语言

前言：为什么我们需要重新思考 Web 上的文本布局？

“The future of text layout is not CSS.”
—— 这是 Pretext 项目给人的第一印象，也是它试图回答的问题。

当你在一个聊天应用中快速滚动消息列表，或者拖拽一个仪表板的边栏来调整布局时，你是否曾感觉到页面突然卡顿、掉帧？背后的元凶，很可能就是文本测量。

浏览器渲染文本的管线，是为三十年前的静态文档设计的：加载、布局、绘制。但在今天的 Web 应用中，文本不再是静态的——它需要实时响应拖拽、动态适应容器、精确参与复杂布局。然而，每一次我们想要知道一段文本的高度，都会触发一次同步的布局重排（reflow）。就像图片中描述的那样：

“Measuring the height of a single text block forces the browser to recalculate the position of every element on the page. When you measure five hundred text blocks in sequence, you trigger five hundred full layout passes.”

这种模式被称为 布局抖动（layout thrashing） ，它是现代 Web 应用中卡顿的最大来源之一。Chrome DevTools 会为此亮起红色警示条，Lighthouse 也会因此扣除性能得分。但开发者别无选择——CSS 并没有提供在不渲染的情况下计算文本高度的 API。文本的尺寸信息被锁在 DOM 背后，而每一次索取，都必须支付高昂的性能代价。

Pretext 的出现，正是为了彻底终结这种困境。

“The performance improvement is not incremental — it is categorical. 0.05ms versus 30ms. Zero reflows versus five hundred.”

1. Pretext 是什么？

Pretext 是一个专注于解决前端文本测量与布局难题的库。它的核心目标是：在不触达 DOM 的情况下，快速、准确地测量一段文本在特定字体和宽度下的高度、行数等布局信息。

它的最大创新点在于：

零 DOM 测量：完全避免了使用 getBoundingClientRect 或 offsetHeight 等会触发浏览器重排（reflow） 的昂贵操作。
自研测量逻辑：它利用 Canvas API 的 measureText 作为测量基准，并通过巧妙的迭代方法逼近浏览器的原生渲染效果。
极致性能：将“文本分析”与“布局计算”分离，实现计算结果的复用，在特定基准下 layout() 阶段仅需约 0.09ms。

因此，Pretext 非常适合用于实现虚拟滚动、复杂自定义布局、开发时校验以及防止布局偏移等高级场景。

2. 核心原理：准备与布局的分离

Pretext 的设计基于一个核心洞察：文本布局计算可以拆分为两个阶段，其中只有第一阶段需要“昂贵”的测量。

2.1 阶段一：`prepare()` —— 文本分析与字符测量

这个阶段做的事情，可以理解为一个“文本编译”过程：

文本规范化：统一处理空白字符、制表符、换行符。
分段（Segmentation） ：将文本按照“可断行”的边界拆分成若干段。这里涉及到 Unicode 标准中的断字规则（UAX #14），以及如何处理混合方向的文本（如阿拉伯语和英语混合）。
字符测量：使用 Canvas measureText 测量每个“段”的宽度。这是整个过程中唯一一次调用浏览器原生测量能力的地方。
缓存结果：所有测量结果被打包成一个不透明的句柄（opaque handle），供后续使用。

为什么是 Canvas measureText？
Canvas 的 measureText 同样会触发布局计算，但它的开销远小于完整的 DOM 布局。更重要的是，它返回的是精确的、与浏览器字体渲染引擎一致的宽度值，这就保证了 Pretext 的计算结果与真实渲染高度一致。

2.2 阶段二：`layout()` —— 纯算术布局

这个阶段接收 prepare() 返回的句柄，以及当前容器宽度 maxWidth 和行高 lineHeight，然后进行纯算术运算：

断行算法：基于预计算的段宽度，模拟浏览器的断行逻辑（默认 word-break: normal + overflow-wrap: break-word），将段组装成行。
累加高度：每行高度固定为 lineHeight，累加得到总高度。
返回结果：{ height, lineCount }。

关键点：layout() 中没有任何 DOM 操作，也没有新的文本测量，只是数学计算。因此，它可以在窗口大小变化时被高频调用，而几乎不产生性能开销。

2.3 性能基准

仓库中给出了一个基准测试快照（500 段文本的批量处理）：

阶段	耗时
`prepare()`	~19ms
`layout()`	~0.09ms

这意味着，即使你的应用有 500 个独立的文本块需要测量，一次性准备的成本只有 19 毫秒，而后续每次窗口 resize 重新计算所有文本块的高度，仅需 0.09 毫秒。这在传统 DOM 测量方式下是不可想象的。

3. API 详解与实战场景

Pretext 提供了两套 API，分别对应两种主要使用场景。下面逐一拆解。

3.1 场景一：仅需测量高度/行数

这是最常用的场景，适用于虚拟滚动、动态容器高度、布局偏移防护等。

核心 API

// 准备阶段：分析文本并测量字符宽度
function prepare(
  text: string,
  font: string,
  options?: { whiteSpace?: 'normal' | 'pre-wrap' }
): PreparedText;

// 布局阶段：计算在给定宽度和行高下的布局信息
function layout(
  prepared: PreparedText,
  maxWidth: number,
  lineHeight: number
): { height: number; lineCount: number };

实战：虚拟滚动中的文本高度

假设你实现了一个聊天消息列表，每条消息文本长度不同，需要精确计算每条消息的高度以实现虚拟滚动。

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

// 消息数据结构
const messages = [
  { id: 1, text: 'AGI 春天到了。', font: '14px -apple-system' },
  { id: 2, text: 'This is a much longer message that might wrap to multiple lines depending on the container width.', font: '14px -apple-system' },
  // ...
];

// 缓存 PreparedText，避免重复准备
const preparedCache = new Map();

function getMessageHeight(text, font, containerWidth, lineHeight) {
  let prepared = preparedCache.get(text + font);
  if (!prepared) {
    prepared = prepare(text, font);
    preparedCache.set(text + font, prepared);
  }
  const { height } = layout(prepared, containerWidth, lineHeight);
  return height;
}

// 在虚拟滚动组件中使用
function estimateTotalHeight() {
  return messages.reduce((sum, msg) => sum + getMessageHeight(msg.text, msg.font, 320, 20), 0);
}

3.2 场景二：手动控制每一行

当需要将文本渲染到 Canvas、SVG 或 WebGL 时，逐行控制是必须的。

核心 API

// 准备阶段：返回更丰富的分段数据
function prepareWithSegments(
  text: string,
  font: string,
  options?: { whiteSpace?: 'normal' | 'pre-wrap' }
): PreparedTextWithSegments;

// 获取所有行（固定最大宽度）
function layoutWithLines(
  prepared: PreparedTextWithSegments,
  maxWidth: number,
  lineHeight: number
): { height: number; lineCount: number; lines: LayoutLine[] };

// 逐行迭代（支持每行不同宽度）
function layoutNextLine(
  prepared: PreparedTextWithSegments,
  start: LayoutCursor,
  maxWidth: number
): LayoutLine | null;

其中 LayoutLine 结构：

type LayoutLine = {
  text: string;      // 该行的完整文本
  width: number;     // 该行的实际宽度
  start: LayoutCursor;  // 起始光标位置
  end: LayoutCursor;    // 结束光标位置
};

实战：Canvas 渲染 + 文本环绕图片

这是 layoutNextLine 的典型应用场景。

import { prepareWithSegments, layoutNextLine } from '@chenglou/pretext';

function renderParagraphWithFloatedImage(ctx, text, font, x, y, columnWidth, image) {
  const prepared = prepareWithSegments(text, font);
  let cursor = { segmentIndex: 0, graphemeIndex: 0 };
  let currentY = y;
  const lineHeight = 24;

  while (true) {
    // 判断当前 Y 坐标是否在图片范围内
    const isBesideImage = currentY >= image.y && currentY < image.y + image.height;
    // 如果在图片旁边，可用宽度 = 列宽 - 图片宽度 - 间距
    const currentWidth = isBesideImage ? columnWidth - image.width - 16 : columnWidth;

    const line = layoutNextLine(prepared, cursor, currentWidth);
    if (line === null) break;

    ctx.fillText(line.text, x + (isBesideImage ? image.width + 16 : 0), currentY);
    cursor = line.end;
    currentY += lineHeight;
  }
}

3.3 辅助功能

// 清除内部缓存，适用于动态切换大量不同字体时释放内存
function clearCache(): void;

// 设置文本分段所使用的区域设置，影响断字规则
function setLocale(locale?: string): void;

4. 实战案例一：The Editorial Engine —— 60fps 的多栏实时重排

“The Editorial Engine” 是 Pretext 能力的一个典型演示。它模拟了一个多栏编辑布局，其中包含可拖拽的圆形（orbs）和实时响应的文本环绕。

在这个案例中：

页面分为多栏（multi-column），每栏内有大量文本。
用户可以拖拽圆形的“障碍物”，改变它们在页面中的位置。
当障碍物移动时，周围文本需要实时调整换行：原本环绕在左侧的文字可能立即变为环绕在右侧，或者从两栏变为单栏。
所有这一切都必须在 60fps 下流畅运行，即每帧计算时间不能超过 16.6 毫秒。

如果使用传统的 DOM 测量方式，每次拖拽都可能触发数十次甚至上百次重排，导致严重的卡顿。而 Pretext 的做法是：

预先准备：对每栏的文本调用 prepareWithSegments，提前完成分段和字符测量。
响应式布局：在拖拽过程中，每一帧都会根据当前障碍物的位置，计算出每一栏内每一段文本的“可用宽度”，然后调用 layoutNextLine 逐行生成文本内容。
渲染到 Canvas：由于 Pretext 可以逐行给出文本内容，这些内容可以直接绘制到 Canvas 上，完全绕过 DOM 的布局引擎。

最终效果是：拖拽时文本的换行位置实时改变，动画丝滑流畅，没有一丝卡顿。

5. 实战案例二：Justification Algorithms Compared —— 超越浏览器的排版质量

CSS 提供的 text-align: justify 采用的是贪婪算法（greedy algorithm） ：从左到右尽可能多地往一行里塞单词，然后均匀拉伸单词间距。这种算法快，但代价是糟糕的排版质量——尤其是在窄栏中，单词间距会变得极不均匀，形成垂直贯穿段落的“河流（rivers）”，严重影响阅读体验。

Pretext 的演示 “Justification Algorithms Compared” 展示了三种对齐方式的精确对比，数据清晰地揭示了差异：

算法	行数	平均偏差	最大偏差	河流空间数
CSS / 贪婪算法	26	86.9%	304.6%	16
Pretext（带连字符）	25	32.7%	93.8%	4
Pretext（Knuth-Plass）	25	13.1%	32.9%	0

解读这些数据：

行数：CSS 贪婪算法产生了 26 行，而两种 Pretext 算法都只有 25 行。这意味着贪婪算法在断行时效率更低，多出了一整行。
平均偏差：指每行单词间距与理想间距的平均偏离程度。CSS 的平均偏差高达 86.9% ，意味着单词间距极不均匀；而带连字符的 Pretext 将偏差降到 32.7%，Knuth-Plass 进一步压到 13.1% ，趋近专业排版。
最大偏差：最差一行的间距偏离程度。CSS 在某一行上出现了 304.6% 的惊人偏差——这意味着单词间距是理想间距的三倍多，产生巨大的视觉裂痕。Knuth-Plass 的最大偏差仅为 32.9%，几乎察觉不到。
河流空间数：垂直贯穿段落的空白间隙数量。CSS 产生了 16 处河流，严重干扰阅读视线；带连字符的 Pretext 减少到 4 处；而 Knuth-Plass 彻底消除了河流。

Knuth-Plass 算法由 Donald Knuth 和 Michael Plass 为 TeX 排版系统开发，至今仍是段落优化的黄金标准。它构建一个所有可行断点的图，然后寻找最短路径——即能让整个段落的间距最均匀的断行组合。在 Web 上实现这个算法一直很困难，因为需要精确的字符宽度测量和高效的图搜索。Pretext 通过其底层的精确测量能力，让这一切成为可能。

6. 实战案例三：Shrinkwrap Showdown —— 精确的最小宽度

CSS 提供了 fit-content 属性，可以让容器宽度“适应内容”。但它的行为是：容器宽度 = 最长行的宽度。如果一个段落有 3 行，最后一行很短，容器仍然会被撑开到第一行的宽度，留下大量空白。

Pretext 的 “Shrinkwrap Showdown” 演示展示了一种完全不同的能力：精确的最小宽度。

使用 walkLineRanges，Pretext 可以：

对给定文本进行二分搜索，寻找最窄的宽度，使得换行后行数不变（即不会因为宽度减小而增加新的行）。
最终得到的是“刚好能容纳所有行”的最小宽度，没有冗余像素。

为什么 CSS 做不到？

CSS only knows "fit-content" — the width of the widest line after wrapping. If a paragraph wraps to 3 lines and the last line is short, CSS still sizes the container to the longest line. There's no CSS property for "find the narrowest width that still produces exactly 3 lines." That requires measuring text at multiple widths and comparing line counts — exactly what Pretext's walkLineRanges() does, without touching the DOM. Pure arithmetic, no reflows, instant results.

这段说明精准地揭示了问题的本质：CSS 的布局引擎是单次确定性的——给定宽度，输出换行结果；但反过来，“给定换行结果（行数），反向寻找最小宽度”这种操作，CSS 并没有提供 API。要完成这个任务，就必须在不同的宽度假设下反复测量文本，并比较行数的变化。

这正是 Pretext 的独特价值所在：

无需 DOM：测量是纯算术的，不触发布局重排。
二分搜索：由于 layout() 极快（0.09ms/500段），可以轻松在几十次迭代内找到精确的最小宽度。
即时结果：整个过程不产生任何视觉抖动，计算完成即可直接使用。

这个能力的应用场景非常广泛：

聊天气泡：让气泡宽度恰好贴合文本，不会因为最后一行短而留下大量空白。
标签系统：每个标签的宽度精确适应其文本，布局更紧凑。
自适应 UI：在响应式布局中，动态调整容器宽度以匹配内容。
工具提示（Tooltip） ：让提示框的宽度刚好包裹多行文本，而不是被最长行撑开。

CSS 目前无法实现这种效果，因为它的布局引擎没有提供“在给定行数约束下寻找最小宽度”的 API。而 Pretext 通过将文本测量与布局计算解耦，让这类过去不可能实现的操作变得轻而易举。

7. 实战案例四：Masonry —— 零重排的瀑布流布局

瀑布流布局（Masonry Layout）是 Pinterest、Unsplash 等网站的经典设计：卡片以列布局排列，每张卡片的高度不同，下一张卡片会放置在当前高度最小的列下方，以实现紧凑的视觉排列。

实现瀑布流布局的传统方式通常是：

将所有卡片渲染到 DOM 中（可能先设为不可见）。
使用 getBoundingClientRect 或 offsetHeight 获取每张卡片的实际高度。
用 JavaScript 计算每张卡片应该放置的列位置，并设置 top 和 left 值。

这个过程中，步骤 2 会触发强制重排（reflow） 。如果卡片数量很多（例如 100 张），浏览器需要反复计算布局，导致页面卡顿、滚动不流畅，甚至在 Chrome DevTools 中出现醒目的红色“强制重排”标记。

Pretext 的 Masonry 演示 提供了一种全新的思路：使用 Pretext 预先计算每张卡片中文本的高度，从而完全避免 DOM 测量。

核心实现逻辑

预测量：在卡片渲染之前，对每张卡片内的文本（标题、正文等）调用 prepare() + layout()，得到精确的文本高度。由于卡片其他元素（图片、边距）的高度是已知的，可以累加得到整张卡片的预测高度。
纯算术布局：使用预测高度计算每张卡片应放置的列位置。所有计算都是算术运算，不涉及任何 DOM 查询或重排。
一次性渲染：计算出所有卡片的位置后，一次性将卡片渲染到 DOM 中（或直接使用绝对定位）。此时布局已经确定，浏览器只需执行一次布局和绘制。

性能优势

与传统方式相比，Pretext 方案带来的提升是数量级的：

方式	DOM 测量次数	重排次数	滚动卡顿风险
传统 DOM 测量	卡片数量（如 100 次）	至少卡片数量次，可能更多	高
Pretext 预测高度	0	1（最终渲染时）	极低

更重要的是，由于文本高度的计算不依赖 DOM，开发者可以在服务端或构建时完成高度预测，甚至在用户交互（如窗口大小改变）时，只需重新执行纯算术的 layout() 即可更新布局，无需再次触碰 DOM。

真实体验

实际体验该演示时，可以明显感受到：无论滚动多快、加载多少卡片，界面始终丝滑流畅，毫无卡顿感。这正是 Pretext 将文本测量移出渲染关键路径后带来的直接效果。

适用场景

内容流应用：如 Pinterest、设计作品集、新闻聚合。
动态高度卡片列表：卡片内容由用户生成，高度不确定。
高性能无限滚动：在滚动加载更多卡片时，预先计算新卡片的高度，避免加载过程中的布局抖动。

这个案例再次印证了 Pretext 的核心价值：将文本测量从渲染关键路径中剥离，让复杂布局拥有可预测的性能表现。

8. 设计哲学与背后的思考

8.1 为什么不用 Intl.Segmenter？

现代浏览器提供了 Intl.Segmenter API 用于文本分段，但 Pretext 的作者选择了自研分段逻辑。原因有二：

性能：Intl.Segmenter 在处理大量文本时仍有性能开销，且无法与 Canvas measureText 的结果直接集成。
控制力：自研逻辑可以精确控制断行规则，并与测量结果深度绑定。

8.2 为什么不用 WebAssembly 字体引擎？

理论上，用 HarfBuzz 等专业排版引擎编译成 WASM 可以得到更精确的结果。但 Pretext 的目标是轻量、易用、与浏览器渲染一致。Canvas measureText 直接使用浏览器的字体引擎，其结果天然与最终渲染一致，这是任何第三方引擎无法保证的。

8.3 关于“准确性”的承诺

Pretext 的目标不是 100% 像素级精确（因为字体渲染本身在不同操作系统上有差异），而是与浏览器默认排版行为足够接近，满足绝大多数前端布局需求。目前它支持的 CSS 属性集是：

white-space: normal 或 pre-wrap
word-break: normal
overflow-wrap: break-word
line-break: auto

对于超出这个范围的场景（如 word-break: keep-all 或自定义连字符），Pretext 可能无法完美处理。

9. 与现有方案的对比

方案	原理	性能	排版质量	适用场景
Pretext	Canvas measureText + 纯算术布局 + 可选 Knuth-Plass	极高（layout ~0.09ms/500段）	可达到专业排版级别	虚拟滚动、Canvas 渲染、高质量排版
DOM 测量	创建隐藏元素，触发重排	低（每次测量都可能重排）	取决于浏览器	一次性测量、非高频场景
CSS 文本布局	浏览器原生引擎	高（但无法获取测量结果）	贪婪算法，质量一般	常规文档流
`canvas` 测量 + 手动计算	自己实现断行逻辑	中等（需反复测量）	取决于实现质量	简单场景

10. 最佳实践与注意事项

10.1 缓存 PreparedText

prepare() 的成本相对较高，因此务必复用其结果。

javascript

// ❌ 不好
function getHeight(text, width, lineHeight) {
  const prepared = prepare(text, '16px Inter');
  return layout(prepared, width, lineHeight).height;
}

// ✅ 好
const cache = new Map();
function getHeight(text, width, lineHeight) {
  const key = text;
  if (!cache.has(key)) {
    cache.set(key, prepare(text, '16px Inter'));
  }
  return layout(cache.get(key), width, lineHeight).height;
}

10.2 字体声明必须与 CSS 一致

font 参数是 CSS font 属性的简写形式，例如 '16px Inter'、'bold 14px "Helvetica Neue"'。如果与 CSS 中实际渲染的字体不一致，测量结果会偏离。

10.3 lineHeight 需要与实际 CSS 行高一致

layout() 中的 lineHeight 用于计算总高度，但它不会影响断行逻辑（断行只依赖宽度）。如果传入的 lineHeight 与实际 CSS 行高不一致，最终高度会偏离。

10.4 系统字体的坑

仓库特别提示：system-ui 在 macOS 上对于 layout() 的准确性不安全。建议使用具体的字体名称，如 'Inter'、'-apple-system' 等。

10.5 清除缓存

如果你的应用会动态切换大量不同的字体或文本，建议适时调用 clearCache() 释放内存。

11. 未来展望

从仓库的活跃度来看（最近一次提交在 2026 年 3 月），Pretext 仍在积极演进。根据 TODO 和开发文档，未来计划包括：

服务端支持：让 Node.js 环境也能使用 Pretext 进行文本测量。
更完整的 CSS 属性支持：如 word-break: keep-all、hyphens 等。
Knuth-Plass 算法的持续优化：让全局最优断行在更多场景下达到实时性能。
性能进一步优化：通过 Web Worker 并行化准备阶段。

12. 总结

Pretext 是一个理念超前、实现精巧的前端基础设施库。它通过将文本测量与布局计算解耦，在保持与浏览器渲染一致的前提下，实现了数量级的性能提升。

但 Pretext 的价值远不止于性能。正如四个演示所证明的：

The Editorial Engine 展示了 Pretext 如何支撑 60fps 的实时交互布局，让拖拽、环绕等复杂排版不再卡顿。
Justification Algorithms Compared 展示了 Pretext 可以带来超越 CSS 的排版质量——全局最优断行（Knuth-Plass）配合音节级连字符，让 Web 上的对齐文字第一次接近专业排版软件的质感。
Shrinkwrap Showdown 展示了 Pretext 可以带来超越 CSS 的布局控制力——精确的最小宽度计算，让容器可以“刚好包裹”多行文本，而不是被最长行撑开。
Masonry 则展示了 Pretext 在零重排瀑布流中的实际落地效果，彻底消除了因高度测量导致的布局抖动。

如果你正面临以下问题，Pretext 值得一试：

需要实现一个包含复杂文本的虚拟滚动列表，但苦于高度测量带来的性能问题。
希望消除动态内容引起的布局偏移（CLS），想在渲染前就知道文本高度。
需要将文本渲染到 Canvas、SVG 或 WebGL，并实现自定义布局（如文本环绕、多栏实时重排）。
追求高质量的排版效果，想让 Web 上的对齐文字更均匀、更专业。
希望实现 CSS 无法完成的精确布局，如“刚好包裹多行文本”的最小宽度容器或高性能瀑布流。

项目核心数据：

作者：Cheng Lou（前 React Core 成员）
语言：TypeScript (89.5%)
性能：layout() 阶段平均 < 0.1ms（500段文本）
热度：GitHub 24.2k Stars
许可证：MIT

“The future of text layout is not CSS.”
这句话不是说要抛弃 CSS，而是说，当我们需要超越 CSS 能力范围的布局控制力和排版质量时，Pretext 这样的工具将填补空白。它让我们重新获得了对文本布局的控制权，同时将性能损耗降到最低。

希望这篇深度指南能帮助你全面理解 Pretext，并在实际项目中发挥它的价值。

注：文中使用的演示 GIF 来自 Pretext 官方示例，完整交互式演示请访问 chenglou.me/pretext。

Pretext 如何颠覆前端文本布局

Pretext 完全指南：高性能文本测量与布局的终极方案

前言：为什么我们需要重新思考 Web 上的文本布局？

1. Pretext 是什么？

2. 核心原理：准备与布局的分离

2.1 阶段一：prepare() —— 文本分析与字符测量

2.2 阶段二：layout() —— 纯算术布局

2.3 性能基准

3. API 详解与实战场景

3.1 场景一：仅需测量高度/行数

核心 API

实战：虚拟滚动中的文本高度

3.2 场景二：手动控制每一行

核心 API

实战：Canvas 渲染 + 文本环绕图片

3.3 辅助功能

4. 实战案例一：The Editorial Engine —— 60fps 的多栏实时重排

5. 实战案例二：Justification Algorithms Compared —— 超越浏览器的排版质量

6. 实战案例三：Shrinkwrap Showdown —— 精确的最小宽度

7. 实战案例四：Masonry —— 零重排的瀑布流布局

核心实现逻辑

性能优势

真实体验

适用场景

8. 设计哲学与背后的思考

8.1 为什么不用 Intl.Segmenter？

8.2 为什么不用 WebAssembly 字体引擎？

8.3 关于“准确性”的承诺

9. 与现有方案的对比

10. 最佳实践与注意事项

10.1 缓存 PreparedText

10.2 字体声明必须与 CSS 一致

10.3 lineHeight 需要与实际 CSS 行高一致

10.4 系统字体的坑

10.5 清除缓存

11. 未来展望

12. 总结

2.1 阶段一：`prepare()` —— 文本分析与字符测量

2.2 阶段二：`layout()` —— 纯算术布局