一个容易被忽略的排版缺陷
打开一篇博客文章，正文段落通常由浏览器自动换行。默认的换行算法只做一件事：在容器宽度内，把单词依次放入每一行，放不下就换到下一行。这种贪心算法速度快，但不会考虑段落的整体形态。于是经常出现这样的结果：一段文字的最后一行只有一个单词，孤零零地挂在段落末尾。排版术语里，这个单词叫“孤行”（orphan）。
孤行不是错误，但会干扰阅读。视线扫过段落时，最后一行太短，眼睛需要多一次回跳，段落的结束感也被削弱。传统上，设计师会手动调整字号、容器宽度，或者用 把最后两个词绑在一起，但这些做法要么只对固定内容有效，要么在响应式布局下失效。
CSS Text Module Level 4 引入了 text-wrap: pretty，目的就是让浏览器用更精细的换行算法，在段落末尾自动消除孤行。它不需要你手动干预，只要一行 CSS。但“更精细”意味着更多计算，这篇文章会以博客正文排版为例，说明 pretty 到底改了什么、和 balance 有什么区别、会带来多少性能开销，以及什么时候值得用。
默认换行算法：快，但不管段落形态
浏览器默认的换行行为由 text-wrap: wrap 定义（这是 text-wrap 的初始值）。它的核心逻辑是贪心：从左到右扫描文本，把尽可能多的单词放进当前行，直到下一个单词放不下，就换行。这个过程只依赖当前行的剩余空间，不参考前后行的情况。
这种算法的优点是快。它只需要一次线性扫描，每行的宽度计算可以复用，因此长段落也能在几毫秒内完成换行。缺点也很明显：它不关心段落末尾会发生什么。当一段文字恰好剩下一个单词能放进最后一行时，孤行就出现了。
另一个相关问题是连字符。如果段落末尾连续几行都以连字符结尾，视觉上会形成锯齿状边缘，阅读体验也不佳。默认算法同样不会考虑这些。
text-wrap: pretty 的目标就是修正这些默认算法的盲区。它仍然基于 wrap 的行为，但允许浏览器使用更慢、更精细的算法，重点处理段落末尾的几行。
text-wrap: pretty 的核心机制：调整末尾几行
pretty 的规范定义是：行为与 wrap 相同，但用户代理会使用更慢的算法，以更好的排版效果取代速度。规范没有规定具体算法，但 Chrome 的实现（从 Chrome 117 开始）遵循了工程师 Koji Ishii 的设计文档，核心思路是：只调整段落的最后四行。
为什么是四行？因为孤行只出现在段落末尾，而调整最后几行足以消除孤行。Chrome 的实现会先按默认算法换行，然后检查最后几行是否满足某些条件（例如最后一行只有一个单词），如果满足，就尝试重新分配最后几行的换行位置，让最后一行至少有两个单词。
这个过程不是全局重排，而是局部优化。它只影响段落末尾的几行，前面的行保持不变。因此，计算量被限制在一个很小的范围内，但仍然比默认算法多出不少工作。
pretty 还处理连字符问题：如果段落末尾出现连续连字符行，它会调整换行位置以减少这种视觉噪声。这些调整都是自动的，不需要额外配置。
与 text-wrap: balance 的差异
text-wrap 还有一个值 balance，常被拿来和 pretty 对比。balance 的目标是让每一行的字符数尽量均衡，通常用于标题、副标题等短文本。它的算法会计算所有可能的换行组合，找到最平衡的方案，因此计算复杂度较高。
为了控制性能，规范允许浏览器限制 balance 作用的行数：Chromium 限制为 6 行以内，Firefox 限制为 10 行以内。超过这个行数，balance 不会生效。MDN 文档明确说明，balance 只适用于短文本，例如标题、引用块。
pretty 则没有行数限制，因为它只调整最后几行，而不是全局平衡。它适用于长段落，比如博客正文。
两者的适用场景完全不同：balance 用于标题，pretty 用于正文。混淆使用会带来问题：如果把 balance 用在长段落上，浏览器会尝试计算平衡，但行数超过限制后不生效，白白浪费性能；如果把 pretty 用在标题上，虽然也能消除孤行，但标题通常只有一两行，效果不明显，反而增加不必要的计算。
下表总结了它们的差异：
| 特性 | text-wrap: balance | text-wrap: pretty |
|---|---|---|
| 主要目标 | 让每行字符数均衡 | 消除孤行，优化段落末尾 |
| 适用场景 | 标题、副标题、引用块 | 长段落、正文 |
| 行数限制 | Chromium 6 行、Firefox 10 行 | 无明确限制，但只调整最后 4 行 |
| 算法复杂度 | 全局搜索，计算量大 | 局部优化，计算量较小 |
| 性能影响 | 短文本可忽略，长文本浪费性能 | 长文本有额外开销，但可控 |
| 浏览器支持 | Chrome、Firefox、Safari 15+ | 仅 Chromium（Chrome 117+） |
性能开销：为什么 pretty 不是免费的
pretty 的性能开销来自它需要多次换行计算。默认算法只需要一次线性扫描，而 pretty 在发现末尾孤行后，需要尝试不同的换行组合，直到找到满足条件的方案。这个过程可能涉及多次回溯，虽然只影响最后四行，但每行的宽度计算、字符测量都需要时间。
Chrome 的设计文档提到，为了平衡排版收益和性能影响，pretty 只调整满足特定条件的段落的最后四行。这意味着并非所有段落都会触发优化，只有那些末尾存在孤行或连字符问题的段落才会进入重排流程。因此，在大多数情况下，额外开销是有限的。
但“有限”不等于“免费”。对于包含大量段落的页面，如果每个段落都触发优化，累计的布局时间会明显增加。MDN 文档明确警告：pretty 对性能有负面影响，应只在排版质量比速度更重要的长文本块中使用。
一个常见的性能陷阱是：把 pretty 应用在动态内容上，比如用户输入或频繁更新的文本。每次内容变化都会触发重新换行，如果段落很长，优化过程会重复执行，导致输入延迟或滚动卡顿。
贯穿场景：博客文章正文的排版优化
假设你运营一个技术博客，文章正文是典型的 HTML 结构：<article> 包含多个 <p> 段落，每段大约 100～200 个中文字符，容器宽度在 600～800 像素之间。默认换行下，你经常看到段落末尾孤零零的一个词，尤其是英文单词或短数字。
你决定尝试 text-wrap: pretty。添加一行 CSS：
article p {
text-wrap: pretty;
}在支持的浏览器（Chrome 117+）中，段落的最后一行会尽量保留至少两个单词。例如，原来最后一行是“performance”，现在可能变成“performance cost”，前一行相应缩短。视觉上，段落末尾不再有突兀的单词，阅读节奏更流畅。
但你也注意到，页面首次渲染的时间略有增加。如果文章很长（比如 50 个段落），每个段落都触发优化，布局时间可能从 10 毫秒增加到 30 毫秒。对于静态页面，这个开销可以接受；但如果页面是服务端渲染后由客户端 hydration，或者在低端移动设备上，这个差异可能被放大。
布局流程与计算次数
为了理解 pretty 的开销，我们需要看它如何影响布局流程。浏览器渲染一个段落时，通常经历以下步骤：
- 样式计算：确定
text-wrap的值。 - 换行计算：根据容器宽度和文本内容，确定每行的断点。
- 布局：根据断点生成行框，计算每个行框的位置和尺寸。
- 绘制：将文本绘制到屏幕上。
默认算法在步骤 2 中只做一次线性扫描。pretty 则可能在步骤 2 中多次迭代：先按默认算法得到初始断点，然后检查末尾是否满足条件，如果不满足，就调整最后几行的断点，重新计算这些行的宽度和位置。
这个过程可以用下面的流程图表示：
flowchart TD
A[开始换行] --> B[按默认算法计算断点]
B --> C{最后一行是否孤行?}
C -- 否 --> D[完成布局]
C -- 是 --> E[调整最后四行断点]
E --> F[重新计算这些行的宽度]
F --> G[检查是否满足条件?]
G -- 是 --> D
G -- 否 --> H[放弃调整，使用默认结果]
H --> D
关键转折点在判断“最后一行是否孤行”。如果段落末尾没有孤行，pretty 不会触发额外计算，开销几乎为零。只有当孤行存在时，才会进入调整流程。调整后如果仍不满足条件（例如文本太短无法凑出两个单词），浏览器会放弃调整，使用默认结果。
因此，pretty 的实际开销取决于段落中孤行出现的频率。在中文文本中，由于单词边界不明显，孤行现象较少；在英文文本中，孤行更常见，触发优化的概率更高。
可观测信号与诊断
如果你在生产环境中使用 pretty，需要关注以下信号：
- 布局时间：使用 Performance API 或 DevTools 的 Performance 面板，测量长段落的布局耗时。如果布局时间明显增加，可能需要考虑是否所有段落都适用
pretty。 - 首次内容绘制（FCP）：如果页面首屏包含大量段落，
pretty可能延迟首次绘制。 - 滚动卡顿：在滚动过程中，如果文本内容动态变化（例如懒加载），
pretty的重新计算可能导致帧率下降。
诊断方法：在 DevTools 中，使用 Performance 面板录制一段滚动或加载过程，查看 Layout 事件的时间线。如果 Layout 事件持续时间超过 50 毫秒，就可能造成可见的卡顿。
另一个信号是浏览器是否实际应用了优化。由于 pretty 是渐进增强，不支持的浏览器会回退到默认换行。你可以通过检查 text-wrap 的计算值来确认：在 Chrome 中，getComputedStyle(el).textWrap 应返回 pretty；在其他浏览器中可能返回 wrap。
与替代方案的比较
除了 pretty，还有其他方法可以处理孤行：
- 手动插入
：在最后两个词之间插入不间断空格，强制它们在同一行。这种方法精确，但需要知道文本内容，无法应对动态内容或响应式布局。 - 使用
orphans属性：CSS 的orphans属性控制块级容器内段落的最小行数，但它只适用于多栏布局，对普通段落无效。 - JavaScript 检测：用脚本检测最后一行是否孤行，然后动态调整样式。这种方法灵活，但需要监听窗口大小变化，可能引入额外的脚本开销。
相比之下，pretty 的优势是零 JavaScript、纯 CSS 声明，且自动适应内容变化。缺点是浏览器支持有限（仅 Chromium），且性能开销不可忽略。
下表比较了这些方案：
| 方案 | 优点 | 缺点 |
|---|---|---|
text-wrap: pretty | 纯 CSS，自动适应，无脚本 | 仅 Chromium 支持，有性能开销 |
手动 | 精确控制，无性能开销 | 需要知道文本内容，不适用于动态内容 |
orphans 属性 | 标准属性，控制最小行数 | 仅适用于多栏布局，对普通段落无效 |
| JavaScript 检测 | 灵活，可针对特定条件 | 增加脚本复杂度，需监听 resize |
使用建议与适用边界
基于以上分析，以下是一些使用建议：
- 优先用于长段落正文：博客文章、新闻内容、文档说明等，这些场景排版质量比性能更重要。
- 避免用于短文本：标题、按钮、标签等，
pretty的效果不明显，反而增加计算。 - 避免用于动态内容：如果文本频繁变化（如用户输入、实时更新），
pretty可能导致布局抖动，此时应使用stable或默认值。 - 作为渐进增强：由于支持有限，可以将
pretty放在 CSS 中，不支持的浏览器自动回退到默认换行，不会破坏布局。
不适用场景包括：
- 性能敏感的应用，如实时协作编辑器、游戏界面。
- 文本非常短的场景，如单行输入框。
- 需要精确控制换行位置的设计稿，
pretty的自动调整可能不符合预期。
未来展望与未解决问题
text-wrap: pretty 目前仍是 CSS Text Level 4 的一部分，规范状态为 Editor’s Draft，尚未成为正式推荐标准。Chrome 从 117 开始支持，但 Firefox 和 Safari 尚未实现。这意味着跨浏览器使用时，需要依赖渐进增强。
规范中还有一个值 avoid-short-last-line，它允许作者明确要求避免最后一行过短，但尚未有浏览器实现。未来，pretty 可能会扩展更多排版优化，例如处理寡行（widow，即段落开头的孤立行）或更复杂的连字符规则。
对于开发者来说，理解 pretty 的机制和代价，有助于在排版质量与性能之间做出明智的权衡。在支持它的浏览器中，一行 CSS 就能显著改善长段落的阅读体验；在不支持的浏览器中，也不会造成任何损害。这种渐进增强的特性，使它成为一个值得尝试的现代 CSS 功能。