Go go-runewidth 的歧义宽度字符为什么在不同环境占列不同

如果 Go 程序在终端里打印表格，普通中文、拉丁字母和符号混在一起时，最容易遇到的现象就是：同一行字符串在一台机器上刚好对齐，换到另一台机器却多出一列或少一列。go-runewidth 的关键答案是：Unicode 的“歧义宽度”只是字符分类，最终占几格还要看 EastAsianWidth 对应的宽度策略；而且 é、ß 这类拉丁字符和 ±、×、○ 这类符号并不是同一种处理结果。

要让表格稳定，不能只用 IsAmbiguousWidth 判断“它是不是歧义字符”。应当在应用边界显式决定是否采用东亚宽度策略，再用同一个 Condition 完成 RuneWidth、StringWidth 和填充计算。

• 歧义分类不等于最终列宽：IsAmbiguousWidth 与 RuneWidth 的语义不同。
• 环境差异来自策略：默认条件会结合当前 locale，EastAsianWidth 改变部分字符的测量口径。
• 布局代码要统一口径：测量、填充、截断必须使用同一个条件对象和同一套目标终端约定。

为什么同一个字符会占不同列

先把“分类”和“测量”拆开。Unicode 把某些字符标为 East Asian Ambiguous，表示在不同东亚排版语境里可能采用窄宽或宽宽。go-runewidth 的 IsAmbiguousWidth 只回答一个字符是否属于这类集合；真正用于排版的是 RuneWidth 或 StringWidth。

官方文档特别说明：ü、é、ß 等 U+0080 到 U+017F 的拉丁字符虽然会被报告为歧义宽度，但即使启用 EastAsianWidth，测量时仍按 1 格处理，因为 CJK 终端通常也把它们画成窄字符。相对地，±、×、○ 等符号在东亚宽度环境中可能占 2 格。

因此，程序只根据 IsAmbiguousWidth(r) 就把所有歧义字符强行加宽，反而会把拉丁字符的结果算错。稳定的做法是把目标终端的宽度约定当作应用配置，而不是把本机语言环境当成不可见的全局开关。

默认条件为什么会把环境带进结果

包中有一个代表当前 locale 的 DefaultCondition，也可以通过 NewCondition() 创建当前环境条件。Condition 暴露了 EastAsianWidth、StrictEmojiNeutral 等选项；如果不同运行环境得到不同的条件，表格宽度自然可能不同。

下面的代码只展示如何把策略显式写进初始化边界。示例不依赖本机默认值：服务端先约定目标终端是否采用东亚宽度，再把同一个条件传给所有格式化函数。

package main

import (
    "fmt"

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

func main() {
    // 显式固定目标终端策略，避免直接依赖运行机器的 locale。
    policy := runewidth.NewCondition()
    policy.EastAsianWidth = true

    sample := "A±é○"
    // StringWidth 返回终端列数，不是字符串的字节数或 rune 数量。
    fmt.Println(policy.StringWidth(sample))
    fmt.Println(policy.FillRight(sample, 12))
}

这里的重点不是某个固定输出数字，而是“测量与填充共享策略”。如果一处使用默认条件，另一处使用显式的东亚条件，边框就可能在同一进程内都无法对齐。

让表格在目标终端稳定对齐

表格格式化器通常需要三类能力：识别特殊字符、计算字符串列宽、按照列宽填充或截断。go-runewidth 已经分别提供了 IsAmbiguousWidth、RuneWidth、StringWidth、FillRight 和 Truncate；应用代码只需要把它们放在同一个 Condition 的语义边界里。

type Formatter struct {
    width *runewidth.Condition
}

func (f Formatter) Cell(text string, limit int) string {
    // 先按列宽截断，避免用 len(text) 把 UTF-8 字节数当成显示宽度。
    clipped := f.width.Truncate(text, limit, "…")
    // 再按同一条件补齐右侧空格，让列边界使用同一套口径。
    return f.width.FillRight(clipped, limit)
}

func newFormatter(eastAsian bool) Formatter {
    // 每个格式化器固定自己的策略，调用方无需读取全局 locale。
    c := runewidth.NewCondition()
    c.EastAsianWidth = eastAsian
    return Formatter{width: c}
}

如果列宽参数来自外部配置，建议在创建 Formatter 时完成策略选择，后续只传递格式化器。这样可以避免某个调用点偷偷切换宽度规则，也便于针对“窄宽终端”和“东亚宽度终端”分别编写示例。

修改条件后要留意查找表和版本边界

官方文档说明，CreateLUT() 会创建内存查找表以加速操作；如果修改了 DefaultCondition 或某个 Condition 的选项，应在并发使用前重新创建对应查找表，而且不能与其他操作并发调用。实际项目里更稳妥的方式是：应用启动时构造好条件，设置完选项后再交给只读的格式化路径，避免运行中途切换。

还要区分三个边界：列宽是终端单元格数量，不是字体的像素宽度；字符串宽度不是 UTF-8 字节长度；不同终端的字体、组合字符和 emoji 渲染仍可能带来视觉差异。go-runewidth 能统一程序侧的列宽计算，却不能替代目标终端的实际渲染约定。

Go go-runewidth 歧义宽度常见问题 FAQ

IsAmbiguousWidth 返回 true 就一定是两列吗？

不一定。它只表示字符属于 Unicode 歧义宽度集合；最终列数要看 RuneWidth 使用的条件，而且官方明确列出了拉丁歧义字符仍按 1 格的例外。

为什么同一程序换到中文环境后表格错位？

通常是默认条件或终端宽度约定发生了变化。把 EastAsianWidth 明确成应用策略，并让测量、填充、截断共用一个 Condition，可以减少这种隐式差异。

能不能直接用 len 计算列宽？

不能把它当成显示列宽。len 统计的是字节数，rune 数量也不等于终端单元格数量；表格对齐应使用 StringWidth 和对应的填充/截断 API。

总结一下：先把歧义分类和最终测量分开，再显式固定 EastAsianWidth 策略，最后让所有布局操作复用同一个 Condition。这样即使部署环境不同，Go 程序也能清楚说明自己针对哪一种终端列宽约定。