Go go-runewidth 的独立 Condition 与全局设置有什么区别

在 Go 程序里用 github.com/mattn/go-runewidth 对齐表格、截断终端标题或计算多语言字符串宽度时，最容易混淆的是“全局设置”和“独立 Condition”。它们都能调用 StringWidth、Wrap、Truncate，但作用域并不相同：包级函数绑定的是 DefaultCondition，而独立实例保存自己的宽度策略。

官方地址：https://pkg.go.dev/github.com/mattn/go-runewidth

如果整个进程只服务一种终端规则，直接使用全局入口最省事；如果同一个进程同时处理 CJK 终端、非 CJK 终端或不同 Emoji 策略，就应该为每种规则保留独立的 Condition。关键取舍不是“哪个 API 更快”，而是配置是否应该被所有调用方共享。

先把全局入口和独立实例放到同一张图里

go-runewidth 的包级 StringWidth、Wrap、Truncate 等函数都会转到 DefaultCondition。因此，调用全局函数时，真正决定宽度的不是某个隐含的调用者配置，而是这个默认实例当前的字段。

NewCondition 则创建一个新的 Condition，初始字段来自当前的包级标志。创建完成后，它就是另一份配置对象；它的方法通过接收者自己的 EastAsianWidth、StrictEmojiNeutral 等字段计算结果。

全局模式适合“一种进程、一套终端规则”

包级变量 EastAsianWidth 表示当前是否按 CJK 环境处理东亚宽度；StrictEmojiNeutral 控制 Emoji 中性宽度的处理方式。DefaultCondition 会在包初始化时建立，并由环境处理逻辑同步相关默认标志。

全局 API 的优点是调用面短，业务代码不必把配置对象层层传递：

package main

import (
	"fmt"

	"github.com/mattn/go-runewidth"
)

func main() {
	text := "订单 ✅"

	// 全局函数使用 DefaultCondition，适合整个进程遵循同一套宽度政策。
	width := runewidth.StringWidth(text)
	fmt.Printf("text=%q width=%d\n", text, width)

	// 修改 DefaultCondition 的字段后，先让默认实例重建自己的查找表。
	runewidth.DefaultCondition.StrictEmojiNeutral = false
	runewidth.CreateLUT()
	fmt.Printf("after-policy-change width=%d\n", runewidth.StringWidth(text))
}

但全局模式有一个结构性代价：所有调用方看见的是同一个策略。如果一个请求想按 CJK 终端计算，另一个请求想按非 CJK 终端计算，直接修改 DefaultCondition 就会让两个请求共享变化。并发服务里不应把“请求级差异”写进包级默认对象。

独立 Condition 把终端规则收回到调用方

独立实例的价值在于隔离，而不是增加一个不同名字的全局变量。可以创建两个实例，分别固定各自的 EastAsianWidth；之后调用 cjk.StringWidth 与 narrow.StringWidth 时，不会因为另一个实例的字段变化而改写配置。

package main

import (
	"fmt"

	"github.com/mattn/go-runewidth"
)

func main() {
	text := "表格 ±"

	// NewCondition 从当前默认标志创建独立实例，之后可分别调整策略。
	cjk := runewidth.NewCondition()
	narrow := runewidth.NewCondition()
	cjk.EastAsianWidth = true
	narrow.EastAsianWidth = false

	// 每个接收者读取自己的字段，两个结果可以在同一进程里并存。
	fmt.Printf("cjk=%d narrow=%d\n", cjk.StringWidth(text), narrow.StringWidth(text))
}

这里要注意 NewCondition 的语义：它不是把未来的全局变化持续同步到实例，而是以当前包级标志为起点创建新对象。若后面再改全局设置，已经创建的 cjk 和 narrow 不会自动跟着变；这正是独立配置可以隔离的原因。

配置字段变了，实例缓存也要跟着处理

Condition.CreateLUT 会为该实例创建组合查找表，官方文档说明它不能与同一实例的其他操作并发执行；如果实例的选项发生变化，也需要再次调用它。这个规则把缓存的责任落在实例上，而不是要求所有 Condition 共享一张表。

因此，配置工厂可以把“创建、设置、预热”放在同一个初始化阶段：

package main

import "github.com/mattn/go-runewidth"

func newCondition(eastAsian bool, strictEmoji bool) *runewidth.Condition {
	condition := runewidth.NewCondition()
	// 先写入最终策略，避免用旧字段建立查找表后又立即失效。
	condition.EastAsianWidth = eastAsian
	condition.StrictEmojiNeutral = strictEmoji
	// 预热只操作这个实例；不要与同一个实例的读操作并发执行。
	condition.CreateLUT()
	return condition
}

如果实例已经被并发请求使用，不要在请求路径里直接修改字段或调用 CreateLUT。更稳妥的做法是创建并准备一个新实例，完成替换后让后续请求读取新指针；旧实例等待读取它的请求自然结束。

高压场景下，真正要隔离的是配置而不是函数名

在单命令行工具里，全局模式通常足够：启动时确定环境，之后只读使用包级函数。到了服务端、渲染服务或多租户导出任务，宽度策略可能随请求、租户或目标终端改变，此时应把 *runewidth.Condition 作为显式依赖传给负责排版的组件。

从架构上看，全局入口是“共享策略服务”，独立 Condition 是“带状态的策略对象”。前者减少参数传递，后者减少跨请求耦合；当系统开始出现不同输出目标时，后者的边界通常更值得保留。

几个容易把作用域弄混的问题

修改 EastAsianWidth 后，所有 Condition 都会变化吗？

不会。修改包级标志影响默认路径；修改某个实例的字段只影响该实例。NewCondition 创建时会读取当前包级标志，但创建后不是动态绑定。

全局 CreateLUT 会为独立实例刷新缓存吗？

不会。包级 CreateLUT 委托给 DefaultCondition.CreateLUT；独立实例应调用自己的方法。

为什么不在每次 StringWidth 前都 CreateLUT？

因为它是缓存建立操作，不是每次读取都要重复执行的步骤。把配置确定和缓存准备放在实例生命周期的初始化阶段，才能避免把管理成本带入高频路径。

结论：用全局默认值承载共识，用独立实例承载差异

go-runewidth 的全局设置和独立 Condition 并不是两套互不相干的算法：全局函数只是默认实例的便捷入口，独立实例则把同一组宽度能力放进可隔离的配置对象。单一终端规则使用全局 API；多种规则并存时创建独立实例，并在字段变化后为对应实例处理 CreateLUT。这样做的重点，是让配置的所有权和缓存的生命周期保持在同一个边界里。