用map[int]string实现错误码映射最简单，但需避免键冲突和并发不安全；错误码应定义为常量，映射表在init()中初始化或用sync.Once延迟加载，动态增删须配sync.RWMutex。
怎么用 map 实现错误码到错误信息的映射
直接用 map[int]string 最简单，但要注意键冲突和并发安全。比如定义全局错误码表时，别在运行时反复初始化，也别在多个 goroutine 里直接写入。
- 错误码建议用常量定义，避免魔法数字：
const ErrNotFound = 404 - 映射表建议在
init()函数里一次性填充，或用sync.Once延迟加载 - 如果需要动态增删（极少见），必须加
sync.RWMutex，读多写少场景下别偷懒用map直接并发读写 - 示例：
var errMessages = map[int]string{ 400: "bad request", 404: "not found", 500: "internal error", }
为什么不能只靠 errors.New 或 fmt.Errorf 做 i18n 错误处理
因为 errors.New 和 fmt.Errorf 返回的是具体字符串，一旦硬编码中文或英文，后续想切语言就得改代码、重编译——这违背 i18n 基本原则。
- 错误值本身应只携带结构化信息（如错误码、原始参数），不带自然语言文本
- 格式化错误信息的逻辑要和错误实例分离，才能对接
go-i18n、localectl等库做翻译 - 常见错误：在
return fmt.Errorf("用户 %s 不存在", name)里拼语言，导致无法本地化 - 正确做法：返回自定义错误类型，含
Code() int和Args() []interface{}方法，再由统一的Translate(err, lang)渲染
用 go-i18n 库做错误信息翻译的实际步骤
go-i18n 不是开箱即用的“错误翻译器”，它本质是通用消息翻译库，得自己把错误码转成 message ID 再查表。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 先定义消息文件，比如
active.en-us.json：{"messages": [{"id": "ERR_NOT_FOUND", "translation": "Resource not found"}]} - 错误实例需实现
MessageID() string方法，返回类似"ERR_NOT_FOUND"的 ID - 调用时用
localizer.MustLocalize(&i18n.LocalizeConfig{MessageID: err.MessageID(), TemplateData: err.Args()}) - 注意：
go-i18nv2+ 要求提前加载 bundle，别在每次错误格式化时重复i18n.MustLoadTranslationFile，会拖慢性能
error code 映射表容易踩的坑
最常被忽略的是错误码语义模糊和层级缺失。比如全用 HTTP 状态码当业务错误码，会导致 400 同时代表“参数缺失”“参数格式错”“权限不足”，前端根本没法区分处理。
立即学习“go语言免费学习笔记（深入）”；
- 业务错误码建议分段设计：前两位表示模块（如
10xxx用户，20xxx订单），后三位递增 - 别复用标准 HTTP 状态码作为唯一标识，至少加一层映射：HTTP 状态码决定响应头，业务错误码决定响应体
code字段 - 日志里只打错误码和关键参数（如
user_id=123），别打翻译后的错误信息——搜索和聚合分析会失效 - 如果用 protobuf 定义错误码，注意
enum值默认从 0 开始，别漏掉UNSPECIFIED = 0占位，否则 JSON 序列化时可能丢失
错误码不是越细越好，关键是前端能据此做明确反馈，后端能据此做精准重试或降级——映射表只是桥梁，真正难的是定义清楚每个码背后的行为契约。
