go 的 error 接口不支持 i18n，需用结构体（如 localizederror）封装原始错误并实现 translate(lang string) string 方法，error() 仍返回默认英文；推荐使用 golang.org/x/text/message 或 text/template + json 翻译文件；语言应从 accept-language 头经中间件注入 context；对外错误必须为 *localizederror，http 响应中需显式调用 translate。
Go 的 error 接口本身不支持 i18n，必须自己封装
Go 标准库的 error 是个只含 Error() string 方法的接口，返回值固定为英文字符串，无法动态切换语言。想实现多语言错误翻译，不能依赖原生 error 类型直接扩展，得用结构体包装原始错误，并把本地化逻辑收拢到自己的错误类型里。
常见错误是试图给 fmt.Errorf 或第三方 error（如 errors.New）直接加翻译字段——这行不通，因为调用方只认 Error() 方法的返回值，而它仍是原始字符串。
- 推荐做法：定义一个带
lang字段和Translate(lang string) string方法的结构体，比如LocalizedError - 原始错误应保存为字段（如
cause error），避免丢失堆栈或链式信息 - 不要重写
Error()去做翻译——它仍需返回默认语言（通常是英文），否则日志、调试、HTTP 错误响应头等场景会混乱
使用 text/template 或 golang.org/x/text/message 实现翻译逻辑
硬编码 map[string]map[string]string 虽简单，但难维护、无复数/性别/顺序支持，也不适配区域变体（如 zh-CN vs zh-TW）。真正可落地的方案只有两个：
-
golang.org/x/text/message：官方推荐，支持 CLDR 规则，能处理复数、占位符顺序、单位格式等；适合需要严谨本地化的服务 -
text/template+ JSON 翻译文件：轻量，适合中小项目；模板中用{{.Code}}、{{.Args}}渲染，配合预加载的map[string]map[string]string
示例（template 方式）：
立即学习“go语言免费学习笔记（深入）”；
type LocalizedError struct {
Code string
Args []interface{}
Cause error
}
func (e *LocalizedError) Error() string {
return fmt.Sprintf("err_%s", e.Code) // 默认英文 code，用于日志分类
}
func (e *LocalizedError) Translate(lang string) string {
tmpl, _ := template.New("err").Parse(translations[lang][e.Code])
var buf strings.Builder
tmpl.Execute(&buf, map[string]interface{}{"Args": e.Args})
return buf.String()
}
HTTP handler 中如何安全注入请求语言并触发翻译
语言偏好应来自请求头（Accept-Language），而非 URL 参数或 cookie——后者易被伪造，且不符合 REST 语义。但直接在每个 handler 里解析又冗余，需要用中间件统一提取并存入 context.Context。
- 中间件中调用
negotiate.ParseAcceptLanguage(r.Header.Get("Accept-Language"))（用 github.com/monoculum/negotiate）获取首选语言 - 用
context.WithValue(ctx, langKey, lang)注入，注意定义私有 key 类型，避免冲突 - handler 内部构造错误时，不再传语言，而是从
ctx.Value(langKey)取；若为空则 fallback 到en
关键陷阱：context.Value 不是类型安全的，建议封装一个 GetLang(ctx context.Context) string 函数做断言和 fallback，别在各处重复 type assert。
错误链中混合原始 error 和 LocalizedError 时的处理策略
真实项目里，你既会用 fmt.Errorf("failed to parse: %w", err) 包装底层错误，也会在业务层抛出 &LocalizedError{...}。两者混用时，%w 会丢失翻译能力，%v 又无法展开 cause。
- 约定：所有对外暴露的错误必须是
*LocalizedError；内部调用可保留原始 error，但进入 handler 前必须转换 - 提供
WrapLocalized(err error, code string, args ...interface{}) *LocalizedError工具函数，自动提取原始 error 的 message 作为Cause，同时保留其类型（方便后续errors.As检查） - 日志打印时，用
fmt.Sprintf("%+v", err)可看到完整链，但翻译只对顶层*LocalizedError生效——这点必须文档化，否则排查问题时容易误以为“翻译没生效”
最易忽略的是：HTTP 响应体中的错误消息必须显式调用 err.Translate(lang)，而不是直接 json.Marshal(err) ——后者只会序列化结构体字段，不会触发翻译逻辑。
