Go x/text/cases Title 为什么没有把每个单词都改成大写

cases.Title 做的是语言相关的标题式大小写转换，不是把每个单词的所有字母全部改成大写。若需要整段大写，应使用 cases.Upper；若需要标题式处理同时保留非词首字母原有大小写，可传入 cases.NoLower。结果还取决于语言规则和单词边界，不能把 Title 理解成按空格拆开后机械修改每段第一个字节。

官方地址：https://pkg.go.dev/golang.org/x/text/cases

先区分标题式大小写与全部大写

设想一个界面要显示 API client。产品说明里的“每个单词大写”可能有两种意思：Api Client 这样的标题形式，或 API CLIENT 这样的全部大写。遇到“转换不生效”时，我会先确认预期文本，而不是直接增加转换调用次数。

Title 默认会对非词首字母做小写处理，因此输入中原本大写的缩写可能发生变化。NoLower 可以阻止这一部分小写操作，但它不会识别所有品牌名、专业缩写或产品专有拼写。若标题必须遵循编辑规范，还需要业务层另外确定保留规则。

用同一输入比较三种配置

下面把三种配置放在同一个函数里，调用方传入同一份文本和同一个语言标记，避免一边换输入、一边换语言导致比较失去意义。

package displaycase

import (
    "golang.org/x/text/cases"
    "golang.org/x/text/language"
)

type Variants struct {
    Title     string
    KeepOther string
    Upper     string
}

// CompareForms 展示三种格式策略，每次调用分别创建 Caser。
func CompareForms(input string, tag language.Tag) Variants {
    // 标题式大小写默认还会对非词首字母做小写处理。
    title := cases.Title(tag)
    // NoLower 只关闭非词首小写，不是全部大写开关。
    keepOther := cases.Title(tag, cases.NoLower)
    upper := cases.Upper(tag)
    return Variants{
        Title: title.String(input),
        KeepOther: keepOther.String(input),
        Upper: upper.String(input),
    }
}

项目需要依赖 golang.org/x/text 模块，版本按现有依赖约束选择。使用 English 和输入 API client 时，按规则预期三种形式分别为 Api Client、API Client 和 API CLIENT。这是示例规则推导，本文没有执行代码或展示运行记录。

确认单词边界和语言选择

官方文档说明 Title 使用默认 Unicode 单词边界算法的近似实现。它没有承诺仅按 ASCII 空格切词。因此撇号、连接符、数字、组合字符等复杂输入，不能单凭界面里看起来分成几段，就推断每段都应该得到独立的词首映射。

语言标记也会影响转换方式。英文、土耳其语、荷兰语等并不共享所有大小写细节。若输入的语言已知，应把对应 language.Tag 作为配置的一部分；language.Und 表示未指定语言，不能替代所有语言特有的规则。

排查时可以保留最小问题文本，确认实际字符和采用的语言标记，再判断是规则与预期不同，还是调用位置有误。不要为了让一个复杂样本符合预期，就将全部文本先按空格切开；这样可能改变词边界和上下文语义。

按完整文本组织转换调用

若一次输入本来是一整个标题，就将完整标题交给 Caser.String。把传输层的数据块当成多个独立标题分别转换，会失去块间的词首判断。例如一段单词恰好在分块处断开，后半段就不应自动变成新的业务单词。

需要流式 Transform 时，应在同一文本期间保留对应转换器状态，并正确处理输入结尾。开始处理下一条独立文本时再按 API 约定重置。本文的 CompareForms 每次创建新的对象，服务于独立完整文本，不承担流式续写职责。

Caser 可能带状态，官方文档因此要求不要在多个 goroutine 之间共享它。对并行转换任务，使用各自的 Caser 更容易维护上下文；不能因为它在 Go 里以值的形式传递，就假定复制后的值拥有完全独立的内部状态。

把显示格式与原始字段分开

我更倾向于把标题式结果作为显示值，而不是覆盖原始字段。原因很具体：默认 Title 可能改变缩写，Upper 可能改变大小写区别，而原始文本后面仍可能用于导出、编辑或比对。记录用户原文，让格式策略成为可调整的展示逻辑，回退更直接。

如果界面必须保留 API、专有产品名等词形，可先明确这份规则的适用范围，再决定是否采用 NoLower 或专门的编辑逻辑。NoLower 只是一个映射选项，不能保证所有名称都得到人工编辑认可的写法。也不要用显示转换结果充当唯一键或原文相等的证明。

常见问题：Title 为什么把 API 变成 Api？这是默认非词首小写处理的结果。加 NoLower 会把 client 全部变成 CLIENT 吗？不会，它不执行整段大写。中文为什么看起来没有变化？没有相应大小写映射的字符不会因为 Title 自动变成另一种字形。多次调用 Title 能修正边界吗？不能靠重复调用替代正确的语言、输入范围和产品预期。

实际排查可以按“期望格式、语言标记、完整输入、选项配置、显示字段”逐项确认。最先解决术语歧义，通常比把大小写函数叠在一起更有效。

参考：Title 官方定义；NoLower 选项与 Caser 使用约定。