Go x/text/message Printer 怎样输出地区数字格式

如果 Go 服务需要把金额、计数或比例显示给不同地区的用户，我会先用 language.Make 得到语言标签，再用 message.NewPrinter(tag) 创建 Printer，最后调用 Printf 或 Sprintf。例如同一个 123456.78，英文、德文、法文和孟加拉语环境会采用不同的分组符号、小数符号或数字形态。

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

这个选择适合“数字值相同，但展示规则跟语言环境变化”的场景。若报表协议要求固定 ASCII 格式，或者结果要给机器继续解析，我仍会使用 fmt 或明确的序列化规则，不把用户界面的本地化格式混进接口字段。

我先把需求拆成两种输出

我在接入本地化输出时，通常先问一个很实际的问题：这段文本是给人看的，还是给程序读的？给人看的金额、数量和统计值，适合交给 message.Printer；给日志、CSV 或 API 消费者的字段，则应该保持约定好的稳定格式。

这个分界很重要：Printer 解决的是本地化展示，不是把所有输出都变成“更适合国际化”的字符串。先决定输出的消费者，后面选择工具会简单很多。

用 language.Tag 创建 Printer

NewPrinter 接收一个 language.Tag，返回一个针对该语言格式化消息的 Printer。标签可以来自 language.Make，也可以由 message.MatchLanguage 按偏好顺序匹配。

package main

import (
	"fmt"

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

func main() {
	amount := 123456.78
	for _, code := range []string{"en", "de", "fr", "bn"} {
		// 每个语言标签创建一个 Printer，让展示规则跟随当前语言。
		printer := message.NewPrinter(language.Make(code))
		// %g 让 Printer 对数字使用地区化的分组和小数规则。
		fmt.Printf("%s -> %s\n", code, printer.Sprintf("%g", amount))
	}
}

官方示例展示了类似的结果：英文可得到 123,456.78，德文可得到 123.456,78，法文使用空格分组和逗号小数，孟加拉语还可能采用本地数字字符。具体展示依赖语言标签和包内的本地化规则，因此不要在业务代码里手写一套“看到德文就替换符号”的分支。

如果语言来自请求头或用户偏好，我更倾向于先完成匹配，再把匹配出的标签传给 Printer：

// preferred 按用户偏好顺序排列，最后一个参数作为回退语言。
tag := message.MatchLanguage("de-CH", "de", "en")
printer := message.NewPrinter(tag)
text := printer.Sprintf("%g", 123456.78)
// text 只用于面向用户的展示；接口字段仍应按协议编码。
_ = text

Printf、Sprintf 和格式动词怎么选

Printer 提供了与 fmt 相近的 Print、Println、Printf、Sprint 和 Sprintf 方法。数字格式化时，文档特别说明 %f、%e、%g 和 %d 默认使用本地化格式；# 标记则会回到 fmt 的打印逻辑。

package main

import (
	"fmt"

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

func main() {
	printer := message.NewPrinter(language.German)
	count := 123456
	rate := 123456.78

	// %d 适合整数计数；Printer 会按当前语言处理数字分组。
	printer.Printf("数量：%d\n", count)
	// %.2f 保留两位小数，适合需要固定小数位的展示值。
	printer.Printf("比例：%.2f\n", rate)
	// # 标记要求回到 fmt 语义，用于需要稳定非本地化格式的特殊场景。
	fmt.Println(printer.Sprintf("%#f", rate))
}

这里的重点不是记住一张格式动词清单，而是把“格式精度”和“本地化开关”分开考虑。%.2f 负责小数位数，语言标签负责展示规则；如果格式字符串带有 #，则不应再假设输出会按地区数字格式处理。

按场景比较 Printer、fmt 和显式格式化

我会把候选方案放进实际边界里比较，而不是只看 API 名称。Printer 的优势是少写地区判断，但它不应该悄悄改变日志、缓存键或接口字段；fmt 的优势是确定性强，但它不会替你完成地区化分组。

例如，一个 HTTP 接口可以同时有两套值：JSON 中保留机器可读的数值，页面模板再用当前用户语言创建 Printer。不要先把数字格式化成带逗号的字符串，再让前端或另一个服务猜回原始数值。

几个容易误用的边界

第一，Printer 不是任意 Go 类型的自动本地化器。官方文档当前明确支持数字以及 x/text 中已有专用类型；像 time.Time 和切片等内置类型并不在当前这套数字示例的支持范围内，不能因为方法名像 fmt 就认为所有值都拥有地区规则。

第二，字符串翻译和数字格式是两件事。格式字符串中出现文本时，Printf、Sprintf 等方法还可能把格式字符串作为翻译键；如果产品真的需要多语言文案，应按文档的 catalog 与翻译流程管理消息，不要只替换数字分隔符。

第三，语言标签应来自明确的用户偏好、请求协商或产品默认值。不要把服务器所在机器的语言环境当成所有用户的语言，也不要用字符串前缀比较代替标准的标签匹配。

我的决策表

相关问题

Printer 能自动把中文金额变成中文大写吗？不能把这件事从本文的数字本地化直接推导出来。中文金额大写是业务格式，需要单独定义规则。

为什么我使用了 Printer，输出看起来还是和 fmt 一样？先检查语言标签、数字类型和格式动词；短数字可能没有分组差异，或者格式字符串带有 #，都会让观察结果与预期不同。

接口返回金额时要不要直接使用 Sprintf？通常不要。接口优先返回数值或固定协议字符串，Sprintf 更适合用户看到的文本层。

我的结论是：把 message.Printer 当作“展示边界的本地化格式化器”，把语言标签和输出消费者一起纳入设计。需要地区化时它能省掉大量手写分支；需要稳定协议时，仍然让 fmt 或显式序列化规则保持主导。