Go x/text/language 置信度低为什么不等于语言标签解析失败

我在排查多语言请求时，曾把 Matcher.Match 返回的 Low 当成了“语言标签没有解析成功”。这个判断会把两个不同阶段混在一起：Parse 负责把字符串解释成 language.Tag，而 Matcher.Match 负责在支持语言列表中选择更合适的结果。

官方文档：https://pkg.go.dev/golang.org/x/text/language

结论是：Low 代表匹配器从多个候选中选出了较可能的值，仍然可能是可用的匹配；真正的解析异常要看 Parse 返回的 error，真正的“没有匹配”要看 confidence == language.No。不要用 Low 代替错误判断。

先分开 Parse 与 Match

语言标签的解析和语言服务的匹配是两个职责。language.Parse 接收 BCP 47 字符串，成功时返回一个标签；如果字符串中有无法接受的部分，它可以同时返回部分解析结果和错误。language.Make 是省略错误的便捷入口，出错时会给出一个合理的默认值，因此不适合用来判断输入是否完全有效。

标签解析成功后，程序还需要回答另一个问题：这个用户偏好应该落到应用支持的哪一种语言上？这才是 Matcher.Match 的工作。它返回匹配后的 tag、支持列表中的 index，以及描述把握程度的 Confidence。

读懂 Low、High、Exact 和 No

Confidence 不是错误类型，而是对返回值确定程度的描述。官方定义中，Exact 表示精确匹配或明确指定，High 表示通常可以认为是正确值，Low 表示从一组候选中选出最可能的值，No 才表示没有匹配。

因此，传统中文和简体中文之间可能返回 Low：匹配器认为它们存在可理解关系，但这不是精确指定。对“选择一个界面语言”这样的业务，Low 往往仍然可以继续使用；对“必须精确区分地区和脚本”的业务，则应把它记录下来，交给更严格的回退策略。

用代码区分 Parse error、Low 和 No

排查时建议先保留解析错误，再单独处理匹配置信度。下面的示例让“输入字符串是否合法”和“支持列表中是否有高把握候选”走不同分支。

package main

import (
    "fmt"

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

func chooseLanguage(input string) (language.Tag, int, language.Confidence, error) {
    // 解析阶段只负责判断输入标签，并保留官方返回的 error。
    preferred, err := language.Parse(input)
    if err != nil {
        return language.Und, -1, language.No, err
    }

    supported := []language.Tag{
        language.SimplifiedChinese,
        language.English,
    }
    matcher := language.NewMatcher(supported)

    // 匹配阶段返回标签、支持列表索引和置信度，三者不要混为一个布尔值。
    tag, index, confidence := matcher.Match(preferred)
    return tag, index, confidence, nil
}

func main() {
    // Low 仍可能有可用的匹配；只有 No 才表示没有匹配候选。
    tag, index, confidence, err := chooseLanguage("zh-TW")
    if err != nil {
        fmt.Println("解析失败：", err)
        return
    }
    if confidence == language.No {
        fmt.Println("没有匹配：", tag)
        return
    }
    fmt.Printf("使用 %s，支持项=%d，置信度=%s\n", tag, index, confidence)
}

这个分支的关键是：err != nil 处理解析阶段的问题，confidence == language.No 处理匹配阶段没有候选的问题，Low 则作为一个有条件可接受的匹配结果继续向下传递。是否接受 Low，应该由业务规则决定，而不是由解析函数替业务决定。

为什么返回的 Tag 不一定等于支持列表中的字符串

在非精确匹配中，Matcher.Match 返回的 Tag 可能和支持列表中的标签不同。官方文档说明，返回值可能携带用户偏好标签中的设置，例如 Unicode 扩展；同时，返回的 index 才是关联应用支持数据的稳定入口。

例如应用的翻译文件、日期格式或货币配置通常按支持列表索引组织，应该使用 index 取得对应资源，再把返回的 tag 交给后续本地化服务。不要因为 tag.String() 与支持列表字符串不相等，就直接判断匹配失败。

func resourceFor(input string, resources []string) (string, error) {
    // Parse 的错误和 Match 的置信度分别记录，便于定位用户输入还是候选列表的问题。
    preferred, err := language.Parse(input)
    if err != nil {
        return "", fmt.Errorf("解析语言标签 %q：%w", input, err)
    }

    supported := []language.Tag{
        language.English,
        language.SimplifiedChinese,
    }
    matcher := language.NewMatcher(supported)
    matched, index, confidence := matcher.Match(preferred)
    if confidence == language.No || index = len(resources) {
        return "", fmt.Errorf("没有可用语言资源：%s", matched)
    }

    // 用 index 关联资源，用 matched 继续初始化语言相关服务。
    return resources[index], nil
}

这里的 index 是“命中了哪一个支持项”，matched 是“匹配结果使用什么标签继续工作”。两者信息不同，不能只保存其中一个。

排查低置信度误判时的四个问题

1. 你检查的是哪个阶段？ 输入字符串的合法性看 Parse 的 error；候选选择的把握看 Confidence。
2. 是否把 Make 当成严格校验？ Make 会省略错误并返回合理默认值，严格入口应保留 Parse 的错误。
3. 是否把 Low 当成 No？ Low 是候选中择优，No 才是没有匹配。两者的业务回退策略不应相同。
4. 是否只比较返回字符串？ 非精确匹配可能保留用户设置，应用资源关联应优先使用 index。

常见问题

Parse 返回了 Tag 和 error，Tag 能不能继续用？

要看业务是否接受部分解析结果。官方接口会在解析失败时返回已经解析出的部分标签，但调用方不应忽略 error；如果业务要求输入完整有效，就应直接走错误分支。

Low 需要立刻报错吗？

不需要一概而论。界面语言回退可以接受 Low，严格地区、脚本或合规标识则可以记录 Low 并要求更明确的输入。它是匹配质量信号，不是语法错误。

为什么不直接比较 tag.String()？

匹配返回的 Tag 可能包含偏好标签中保留下来的设置，且支持列表还有一个明确的索引。需要绑定翻译资源时，应使用返回的 index；需要初始化本地化服务时，再使用返回的 Tag。

可以把这条排查规则记成一句话：先用 Parse 判断标签能否被接受，再用 Matcher.Match 判断它落到哪个支持项；Low 表示“有候选但不够确定”，并不等于“解析失败”。