Go uniseg 怎样判断一段文本允许换行的位置

我第一次给多语言文本做自动换行时，先想到的是按 rune 遍历，再在宽度超限的位置切一刀。这个方案遇到组合字符、emoji 和中日韩文本后，很快就会暴露出边界问题：能不能拆开是一回事，拆开之后是否仍然符合 Unicode 的换行规则又是另一回事。

官方地址：https://pkg.go.dev/github.com/rivo/uniseg

在 github.com/rivo/uniseg 中，我更愿意把这件事看成一个“边界查询”模式：先按 grapheme cluster 观察用户感知的字符单元，再查询当前单元后面是禁止换行、可以换行，还是必须换行。真正决定何时落刀的，仍然是调用方的行宽和排版策略。

先把换行判断拆成三个状态

uniseg 实现 Unicode Line Breaking 规则，并通过 LineBreak() 把当前 grapheme cluster 后面的状态交出来。三个常量的职责很清楚：

这个区分很重要：LineCanBreak 不是“库已经替你换行”，而是把一个合法候选点交给上层。换句话说，uniseg 负责判断规则允许什么，渲染器或文本布局器负责判断当前宽度是否已经值得换行。

我实际使用时先遍历 grapheme cluster

如果需要把每个可选断点记录下来，最直观的入口是 NewGraphemes。它按用户感知的字符簇推进，调用 LineBreak 时，查询的是“当前 cluster 之后”的换行状态，而不是任意字节偏移。

package main

import (
    "fmt"

    "github.com/rivo/uniseg"
)

func printBreakPoints(text string) {
    g := uniseg.NewGraphemes(text)
    for g.Next() {
        from, to := g.Positions()
        // 位置是原始 UTF-8 字符串中的字节区间，不是 rune 下标。
        status := g.LineBreak()
        switch status {
        case uniseg.LineDontBreak:
            fmt.Printf("[%d:%d] %q -> 禁止\n", from, to, g.Str())
        case uniseg.LineCanBreak:
            fmt.Printf("[%d:%d] %q -> 可选\n", from, to, g.Str())
        case uniseg.LineMustBreak:
            fmt.Printf("[%d:%d] %q -> 必须\n", from, to, g.Str())
        }
    }
}

func main() {
    // 文本故意包含空格、中文和换行，便于观察不同边界。
    printBreakPoints("Go 文本\n排版")
}

这里有两个我觉得值得保留的工程习惯。第一，使用 g.Str() 展示当前 cluster，不要把 string(g.Runes()) 当成断点的唯一依据。第二，如果要把断点保存为原文切片，使用 Positions() 返回的字节区间；它和 Go 字符串底层表示一致，但不能当成字符数量。

LineCanBreak 是候选位置，不是自动换行命令

这正是最容易误用的地方。我会把 LineCanBreak 当作“排版系统可以考虑的落刀点”，再把当前行宽、下一个 cluster 的宽度和最小孤行规则放在调用方处理。这样做的好处是，库的 Unicode 规则和产品自己的版式策略不会互相污染。

例如，下面的函数只负责判断当前 cluster 是否提供了合法候选点；它没有假装自己知道字体宽度，也没有把候选点直接改写成换行符：

func isCandidateBreak(g *uniseg.Graphemes) bool {
    // 可选断点只表示规则允许，最终是否换行要由行宽策略决定。
    return g.LineBreak() == uniseg.LineCanBreak
}

func isHardBreak(g *uniseg.Graphemes) bool {
    // 硬换行交给上层强制处理，不能与普通空格断点混为一谈。
    return g.LineBreak() == uniseg.LineMustBreak
}

如果你的目标是终端或等宽文本，还要另外考虑 Graphemes.Width() 或 StringWidth。换行规则告诉你“哪里合法”，宽度计算告诉你“这一行装不装得下”，二者是互补信息，不是同一个判断。

只需要首个行段时，改用 FirstLineSegmentInString

后来我发现，有些场景并不需要保存所有断点，只需要从一段字符串中取出当前行能放下的第一段。这时可以从 FirstLineSegmentInString 开始，连续传递返回的 state，让库继续处理跨段规则。

package main

import (
    "fmt"

    "github.com/rivo/uniseg"
)

func firstSegments(text string) {
    state := -1
    rest := text
    for len(rest) > 0 {
        var segment string
        var mustBreak bool

        // state 用于把前一段的 Unicode 边界上下文交给下一次调用。
        segment, rest, mustBreak, state = uniseg.FirstLineSegmentInString(rest, state)
        fmt.Printf("segment=%q mustBreak=%v\n", segment, mustBreak)
    }
}

这个函数的返回值适合“按 Unicode 规则逐段消费”的任务，但它仍然不是完整的排版器：如果产品要按像素、终端单元格或自定义惩罚分数折行，就需要在外层记录候选边界，结合自己的宽度模型决定最终切分。

这个模式的代价与适用范围

从体验上看，这套做法的优点是边界责任很稳定：uniseg 负责 Unicode 分段与换行分类，调用方负责宽度、缓存和最终渲染。组合字符和 emoji 不会因为简单的 rune 切片被随意拆开，硬换行也不会被普通候选点掩盖。

代价也同样明确：你仍然要维护自己的行宽策略；如果要在大量文本上保存位置，还要理解字节偏移与用户感知字符数量不是一回事。对只处理 ASCII、且规则极简单的内部脚本，这个依赖可能显得偏重；对聊天消息、终端表格、编辑器或多语言日志，则更值得把边界交给专门库。

• 只想知道某个 cluster 后能否断开：使用 Graphemes.LineBreak。
• 需要同时拿到字节区间：使用 Graphemes.Positions，不要把它当 rune 索引。
• 需要连续取首个合法行段：使用 FirstLineSegmentInString 并传递 state。
• 需要决定一行能放多少：把换行状态与 Width 或自己的宽度模型组合。

常见疑问

LineCanBreak 和 LineMustBreak 有什么区别？

LineCanBreak 是可选断点，是否使用取决于行宽和排版策略；LineMustBreak 是必须断开的边界，调用方不应把它当成普通候选点。

为什么不直接按 rune 下标切字符串？

rune 是 Unicode code point，不等于用户感知的 grapheme cluster。组合字符、区域指示符和 ZWJ emoji 都可能由多个 code point 组成，按 rune 切分可能把一个视觉字符拆开。

Positions 返回的是字符位置吗？

不是。它返回原始 Go 字符串中的字节区间；这个结果适合做 text[from:to]，但不能直接当成 UI 字符数。

我的判断是：需要“哪里允许换行”时，先让 uniseg 给出 Unicode 层面的边界分类，再在自己的排版层决定“何时真的换”。这比把换行、宽度和渲染揉成一个循环更容易解释，也更容易在需求变化时替换其中一层。