golang.org/x/text/message 不支持运行时语言切换，因 printer 在创建时固化格式规则；需用 go-i18n/v2 等支持动态本地化的库，并配合 accept-language 安全解析与模板安全插值。
Go 的 golang.org/x/text/message 为什么切不了语言？
它压根不是为运行时动态切换设计的，只是编译期本地化格式化工具。你调 message.NewPrinter 后再换 locale，打印结果不会变——因为格式化规则在创建时就固化了。
常见错误现象：printer.printf("Hello") 始终输出英文，哪怕你改了系统 locale 或传了新 language.Tag；或者用 message.SetString 注册翻译，但没配对 message.Catalog，结果还是 fallback 到源字符串。
- 真正需要的是「按请求动态绑定语言」，得自己维护
map[language.Tag]*message.Printer缓存 - 每次 http 请求进来，先解析
Accept-Language，用language.Parse转成language.Tag，再查缓存或新建Printer - 别把
message.Printer存成全局单例——它不带语言上下文，硬塞进去只会误导自己
用 go-i18n v2 还是 localectl？
v2（github.com/nicksnyder/go-i18n/v2/i18n）是目前最稳的选择：支持 json/ TOML 多格式、可热重载、自带 Bundle 管理和 Localizer，且不依赖 golang.org/x/text 的复杂 API。
localectl 是个轻量 wrapper，但缺失关键能力：无法处理复数（plural）、性别（gender）、嵌套占位符，也不支持运行时加载新语言包。
立即学习“go语言免费学习笔记（深入）”；
- 如果你要支持中文/英文/阿拉伯语（需 RTL + 复数规则），必须用
go-i18n/v2 - 配置路径建议统一放
./locales/{lang}/messages.toml，避免硬编码路径拼接 - 热重载只对文件系统生效；用 embed 打包进二进制后，
bundle.Reload会静默失败，得提前检查fs.Stat
HTTP 请求里怎么安全提取用户语言偏好？
别直接信 r.Header.Get("Accept-Language") 返回的原始字符串——它可能为空、格式非法、含不支持的语言码，甚至被恶意构造（比如超长 header 触发 panic）。
正确做法是用 language.ParseAcceptLanguage 解析，它会自动排序、过滤无效 tag、匹配已注册语言集。
- 先预定义支持列表：
supported := []language.Tag{language.English, language.Chinese, language.Arabic} - 再调
language.ParseAcceptLanguage(r.Header.Get("Accept-Language"))，返回有序候选 tag 列表 - 遍历候选 list，用
language.MatchStrings(supported, candidate.String())找第一个匹配项；没匹配上就 fallback 到默认语言 - 注意：浏览器发的
zh-CN和你配置的zh不等价，得靠language.NewMatcher做宽松匹配
模板里怎么让 html/template 安全插值翻译文本？
直接在模板里调函数容易漏转义，比如翻译内容含 <script></script> 或用户输入数据，不处理就会 xss。Go 模板的 {{.Text}} 默认是 HTML-escaped，但翻译函数返回的字符串已经是纯文本，不该再逃逸一次。
解决方案：写一个自定义 template func，内部用 template.HTML 包装，但仅限可信的翻译源。
func makeT(localizer *i18n.Localizer) func(string, ...interface{}) template.HTML { return func(key string, args ...interface{}) template.HTML { msg, _ := localizer.LocalizeMessage(&i18n.Message{ID: key}, args...) return template.HTML(msg) } }- 注册到模板：
tmpl.Funcs(template.FuncMap{"t": makeT(localizer)}) - 模板中用
{{t "welcome_user" .Name}}，而非{{.T "welcome_user" .Name}}—— 后者如果 T 是普通 string 返回，会被双层 escape - 禁止把用户输入直接塞进
key参数，否则可能触发未定义消息 fallback，暴露内部 key 名或引发 panic
实际最难的不是选库或写函数，是确保所有语言包的 key 全局唯一、无遗漏、无拼写差异；上线后新增一个字段，漏翻一条 en.json 里的 key，对应页面就显示英文——这种问题没法靠测试覆盖，只能靠 CI 阶段做 key 对齐校验。