应调用 http.ParseAcceptLanguage() 解析 Accept-Language 头，按权重排序取首个匹配支持语言的标准化标签，未命中则 fallback 至默认语言；每个请求需独立创建 *message.Printer 实例并绑定到 context，避免复用导致语言错乱。
中间件里怎么拿到客户端语言偏好
浏览器发来的 Accept-Language 是个逗号分隔的带权重字符串，比如 zh-CN,zh;q=0.9,en-US;q=0.8,en;q=0.7。直接用 c.Request().Header.Get("Accept-Language") 拿到原始值后，不能硬拆，得靠标准库 http.ParseAcceptLanguage() 解析——它返回 []string，按优先级排序，第一个就是最该用的语言标签。
常见错误是只取 header 第一个字段、忽略 q 权重，或没 fallback 到默认语言（比如没匹配上就 panic 或返回空）。正确做法是：解析后遍历列表，对每个 tag 做标准化（转小写、去空格、截断到主语言如 zh-cn → zh），再查你支持的语言集；没命中就兜底到 en 或配置的 defaultLang。
为什么不能复用同一个 localizer 实例
Go 的 i18n.Localizer（来自 golang.org/x/text/language + golang.org/x/text/message）本身不是并发安全的，且内部缓存了语言上下文。如果在中间件里全局声明一个 localizer 变量，然后所有请求都调用它的 Localize 方法，就会出现语言错乱：请求 A 设置为 zh，还没返回，请求 B 把它改成 en，A 最终渲染出英文。
- 必须在中间件内为每个
echo.Context单独生成*message.Printer或封装好的T函数 - 推荐方式：用
message.NewPrinter传入解析出的language.Tag，再把Printer绑定到c.Set("T", printer) - 避免在 handler 里重新 new
Printer，否则每次调用都新建对象，GC 压力大
如何在 handler 中安全调用翻译函数
绑定之后，handler 里通过 c.Get("T") 取出 interface{}，需要断言成 *message.Printer。别忘了加类型检查和 panic 防御——中间件执行失败时 "T" 可能不存在。
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
示例用法：
func getUser(c echo.Context) error {
t, ok := c.Get("T").(*message.Printer)
if !ok {
return echo.NewHTTPError(http.StatusInternalServerError, "no translator available")
}
name := c.Param("name")
return c.JSON(http.StatusOK, map[string]string{
"msg": t.Sprintf("Hello, %s", name),
})
}
注意：t.Sprintf 不是线程安全的，但因为每个请求的 t 是独立实例，所以没问题；不要把它存成包级变量或塞进结构体长期持有。
容易被忽略的边界情况
真实线上环境里，Accept-Language 并不可靠：移动端 WebView 可能不发、CDN 或反向代理可能篡改、用户手动设错语言导致 tag 格式非法（如 zh__CN）。这些都会让 http.ParseAcceptLanguage() 返回空 slice 或 panic。
- 务必用
defer func() { if r := recover(); r != nil { /* fallback to en */ } }()包住解析逻辑 - 支持 URL 查询参数覆盖，比如
?lang=ja，优先级高于 header（方便测试和调试） - 如果用了 JWT，也可以从 token payload 里读
lang字段，比 header 更可信 - 日志里记下最终选中的语言 tag，排查错译时能快速定位是解析问题还是资源文件缺失
多语言不是加个中间件就完事，关键在每层都守住「单请求、单语言、单实例」这个边界——漏掉任何一环，错译就会静默发生，而且很难复现。
