Go x/text/width Fold 怎样统一全角半角表现

Go 可以用 width.Fold.String(input) 将字符映射到规范宽度形式，例如将全角拉丁字母与数字折叠为普通形式。Fold 并不表示“所有文字都转半角”：部分半角字符会映射到对应的宽字符。要尽量采用窄形式或宽形式，应分别了解 Narrow 与 Widen 的语义。

官方文档入口：https://pkg.go.dev/golang.org/x/text/width。我会把 Fold 当作输入规则的一部分，用于业务允许忽略宽度差异的检索字段；原始展示文本仍然保留。这里讨论采用这项能力的理由与影响，不将它包装为某个新版本刚发布的功能。

把宽度统一理解为文本规则变更

表单输入中，ＡＢ１２ 与 AB12 看起来接近，但不能因此直接认为其字符串字节相等。如果业务要求它们按同一规则检索，可以先生成统一的匹配文本，再由匹配模块使用。我的取舍是让这层转换靠近字段入口，避免在不同查询分支各写一段手工替换。

手工减去固定偏移量只覆盖某些码点范围，容易漏掉日文半角字符及符号。width 包使用字符宽度属性处理这些映射，适合减少自建映射表，但选择哪些字段采用仍是业务决定。密码、签名原文或要求逐字保真的标识，不应因为展示相近就直接套用转换。

图中的业务目标、Fold、Narrow、Widen、规范形式、窄宽变体分别表示选择依据、转换器及其结果类型；连线只表示配置依赖与能力归属。

Fold 与全部转半角有什么区别

例如全角 Ａ 的 Fold 结果可为 A，而半角片假名 ｶ 的 Fold 结果可为 カ。这是依据映射规则说明的预期，不是本文运行输出。中文汉字也不会因此变成 ASCII；大小写、繁简、空格清理等是另外的需求。

Fold 的官方说明指出它采用规范宽度，Narrow、Widen 则面向对应变体。文档也提示 norm 包中的 NFKC、NFKD 涉及更一般的折叠机制，不能因为两者都能改变一些字符就随意互换。

给字符串增加明确的宽度处理入口

下面的函数显式要求有效 UTF-8，返回宽度折叠后的匹配文本。它不会修改传入变量，也没有承诺生成唯一标识。项目应通过 go.mod 使用与工具链兼容的 x/text 版本。

package matchtext

import (
    "fmt"
    "unicode/utf8"

    "golang.org/x/text/width"
)

// FoldMatchText 生成业务允许忽略宽度差异的匹配文本。
func FoldMatchText(input string) (string, error) {
    // 拒绝非法 UTF-8；宽度转换不负责决定源数据修复策略。
    if !utf8.ValidString(input) {
        return "", fmt.Errorf("输入不是有效 UTF-8")
    }
    // String 直接返回字符串，不是 result、n、err 三个值。
    return width.Fold.String(input), nil
}

这个错误返回来自本文的输入约束，而不是 width.Fold.String 自带的错误返回。若已有上游确保 UTF-8 有效，可以把判断放到统一入口；若来源编码不是 UTF-8，则应先完成字符集解码，再处理宽度。直接 string(raw) 不会把其他字符集自动转换为 UTF-8。

保留原文并统一写入和查询规则

采用 Fold 后，我会分别保存原始文本与匹配文本，让显示组件使用原始文本，让检索模块使用匹配文本，并记录规则版本。查询输入也要采用同一规则，否则只改变存储端，用户输入全角查询时仍可能匹配不到。

图中原始文本、匹配文本、规则版本、显示组件、检索模块、查询输入六个节点对应这一设计。显示组件关联原始文本，检索模块关联匹配文本和查询输入；匹配文本与查询输入的处理都依赖规则版本。

存量字段原先未做转换时，应先决定是否回填匹配文本，再切换查询。转换可能使不同原文产生相同结果，因此现有唯一约束需要单独评估冲突处理。不要把 Fold 结果覆盖原文后才发现无法还原用户输入；映射通常不能靠 Widen 反向恢复。

采用前怎样判断是否符合需求

我会用本业务中的全角拉丁、普通拉丁、数字、片假名和必须保真的符号整理预期对照，重点看是否出现不该合并的文本。本文提供实现与对照方法，没有声称已运行代码或完成生产迁移。

Fold 可以解决大小写不一致吗？不能将字符宽度折叠等同于大小写折叠；若需要忽略大小写，应另行选定规则并确保写入与查询一致。

为什么终端里还是没有对齐？Fold 改的是文本码点，最终显示还涉及字体与渲染环境，不能用它代替终端列宽计算或网页排版。

能把 Fold 当成 NFKC 吗？不能直接等同，两者处理范围不同。需要 Unicode 规范化时，应选择相应 norm 形式，而不是凭几个相同示例推断等价。

如果目标是业务允许的宽度不敏感匹配，我倾向于用 Fold 生成独立字段；如果目标仅仅是把所有有窄变体的字符显示成窄形式，就应该先看 Narrow。明确目标之后再采用接口，比把所有差异混成“全角半角问题”更可控。