Go x/text/unicode/bidi Paragraph 怎样读取混合方向文本段落

处理聊天消息、账单说明或多语言文档时，一行文字里可能同时出现中文、英文和从右向左书写的文字。此时不要直接按 Go 字符串切片来猜“屏幕上应该先显示谁”：golang.org/x/text/unicode/bidi 的 Paragraph 可以先保存一段文本，再按 Unicode 双向文本规则计算方向和 run。

核心做法：用 SetString 配置一个段落，用 Direction 读取整体方向；需要按视觉顺序读取时调用 Order，再遍历 Ordering.Run(i)。每个 Run 的字符串仍是原文顺序，视觉顺序体现在 run 的排列上，而不是把 run 内的字符反转。

官方参考地址：https://pkg.go.dev/golang.org/x/text/unicode/bidi

先分清 Paragraph、Ordering 和 Run

我第一次处理混合方向文本时，最容易混淆的是“段落方向”和“可显示顺序”其实是两层信息。Paragraph 保存一段待处理文本；Ordering 是对这段文本计算出的视觉 run 顺序；Run 则是一个连续的单一方向文本区间。

官方文档还提示这个包的 API 仍处于 under construction 状态，因此应把依赖版本锁在项目的 module 文件中，升级时再重新查看 API 说明。

用 SetString 配置一段混合方向文本

SetString 会替换 Paragraph 中之前配置的内容，并返回消费的字节数和错误。若输入包含段落分隔符，当前调用只处理第一个段落，返回值会包含这个分隔符消耗的字节数。不要把包含多段文本的长字符串直接当成一个段落再自行猜边界。

package main

import (
	"fmt"

	"golang.org/x/text/unicode/bidi"
)

func main() {
	// 这段输入同时包含从左向右和从右向左的文字，适合观察 run 边界。
	input := "订单 Go-42：שלום 已支付"

	var paragraph bidi.Paragraph
	consumed, err := paragraph.SetString(
		input,
		bidi.DefaultDirection(bidi.LeftToRight),
	)
	if err != nil {
		// 配置失败时不要继续调用 Order，先把错误交给上层。
		panic(err)
	}

	fmt.Printf("consumed bytes: %d, direction: %v\\n", consumed, paragraph.Direction())
}

DefaultDirection 只是给没有明确方向字符的内容提供默认值；如果文本本身含有方向性字符，文档说明实际方向会被文本覆盖。因此它不是把混合文本强行变成从左到右。

用 Order 和 Run 读取视觉顺序

调用 Order 后，返回的 Ordering 表示整段文字中各个 run 的视觉排列。遍历 NumRuns，再读取每个 run 的 Direction、Pos 和 String，就能把“显示布局需要的顺序”和“原文定位需要的位置”同时保留下来。

func printVisualRuns(input string) error {
	// Paragraph 只负责一段文本；每次替换文本后都应重新获取 Ordering。
	var paragraph bidi.Paragraph
	if _, err := paragraph.SetString(input); err != nil {
		return fmt.Errorf("set paragraph: %w", err)
	}

	ordering, err := paragraph.Order()
	if err != nil {
		return fmt.Errorf("compute bidi order: %w", err)
	}

	for i := 0; i 

这里有三个实用判断：

• ordering.Direction() 反映 run 的方向性，可以是左到右、右到左、混合或中性。
• run.Pos() 给出它在传给 SetString 的原始文本中的位置，适合回查原文或建立布局索引。
• run.String() 和 run.Bytes() 返回 run 的原始顺序；不要因为它是右到左 run 就再次手工反转。

也就是说，渲染器可以按 Ordering.Run(i) 的顺序布置 run，但业务日志、搜索索引或定位提示仍可使用 Pos 和 String 对应回原文。

需要按行或按位置时，不要重复计算整段

全文 Order 适合先拿到整段的 run 列表，但排版系统通常还要处理行宽。此时可以按原文区间调用 Line(start, end)，让包只计算一行的视觉 run 顺序；如果正在寻找合适的换行点，可以使用 RunAt(pos) 找到指定位置所在的 run。

选择方法时可以记住这条规则：

• 只需要知道段落是 LTR、RTL、Mixed 还是 Neutral：调用 Direction。
• 需要整段的视觉 run：调用 Order，然后遍历 Ordering。
• 已有一行的原文起止位置：调用 Line，不要把整段结果硬切成一行。
• 需要根据某个原文位置做断行或定位：调用 RunAt。

最容易踩的两个生命周期边界

第一，SetString 或 SetBytes 会使原来的 Ordering 失效。正确顺序是“配置文本 → 计算 Ordering → 消费 Ordering”；如果复用同一个 Paragraph 放入新字符串，就必须重新调用 Order。

第二，Ordering 的方法不要被多个 goroutine 同时调用。若要并发处理多条消息，较稳妥的方式是每条消息独立持有自己的 Paragraph 和 Ordering，或者在应用层明确串行消费同一个结果。

如果输入本身包含多个段落，应先按业务规则拆分，再对每个段落单独配置；不要依靠 SetString 的 consumed 值把一整篇文档自动当作多个可渲染对象。

最后按任务做选择

混合方向文本的关键不是“把字符串倒过来”，而是保留原文索引，同时让 bidi 包告诉你每个方向 run 的视觉排列。用 Direction 做整体决策，用 Order 处理整段，用 Line 和 RunAt 服务具体排版边界，代码就不会把展示顺序和原文顺序混为一谈。

常见问题

Paragraph.SetString 为什么返回 consumed？

它表示从输入字符串中消费的字节数；遇到段落分隔符时，当前调用只处理第一个段落并把分隔符计入消费量。

Run.String() 会返回视觉方向上的倒序字符串吗？

不会。官方文档说明它返回 run 的原始顺序；视觉顺序由 Ordering 中 run 的排列表达。

改了 Paragraph 的内容后还能复用旧的 Ordering 吗？

不能。重新调用 SetString 或 SetBytes 后，应重新调用 Order 或 Line 获得新的结果。