Go HTTP handler需手动解析Accept-Language头，按q值排序匹配支持语言；推荐使用github.com/nicksnyder/go-i18n/v2/i18n，避免context传localizer，前端通过API或全局对象同步翻译。
Go HTTP handler怎么读取Accept-Language头并选语言
Go标准库不自动解析Accept-Language，得自己拆、排序、匹配。别指望req.Header.Get("Accept-Language")返回就能直接用——它是一串带权重的逗号分隔值，比如zh-CN,zh;q=0.9,en-US;q=0.8,en;q=0.7。
实操建议：
- 用
http.Request.Header.Get("Accept-Language")取原始值，空时默认"en" - 用
parseAcceptLanguage（或第三方如golang.org/x/net/webdav/accept里的逻辑）拆解，按q值降序排，优先取第一个有效匹配项 - 只比对语言主标签（
zh、en），忽略子标签（zh-CNvszh-TW）除非你明确支持细分区域 - 别在中间件里硬编码语言列表；把支持的语言集抽成
var supportedLangs = []string{"en", "zh", "ja"}，后续增删不改逻辑
用go-i18n还是localectl？选哪个更稳
go-i18n（v2）已归档，官方不再维护；localectl太轻、没上下文支持；目前生产推荐github.com/nicksnyder/go-i18n/v2/i18n（注意是v2分支）或github.com/gogf/gf/v2/os/gi18n（如果项目已在用gf框架）。
关键差异点：
立即学习“go语言免费学习笔记（深入）”；
-
i18n.MustLoadMessageFile会panic，线上必须用i18n.NewBundle.LoadMessageFile+ 显式错误检查 - 消息文件格式：v2只认
.toml或.json，不支持.yaml；字段名必须小写（hello = "Hi"），大写会静默忽略 - 模板中用
{{.T "login.title"}}这类语法时，确保.T是传入的*i18n.Localizer实例，不是字符串函数 - 加载多语言文件时路径要绝对——相对路径在
go run和go build下行为不一致，建议用embed.FS打包进二进制
HTTP中间件里怎么安全传localizer到handler
不能把*i18n.Localizer塞进context.WithValue然后全链路透传——容易漏、难调试、类型不安全。正确做法是封装一个带本地化能力的http.Handler实现。
实操建议：
- 定义结构体：
type i18nHandler struct { next http.Handler; bundle *i18n.Bundle } - 在
ServeHTTP里根据req解析出lang，调用bundle.Localize(&i18n.LocalizeConfig{Language: lang})生成*i18n.Localizer - 用
http.HandlerFunc包装业务handler，在闭包里把localizer作为参数传入，而不是塞context - 避免在中间件里做
localizer.Localize调用——那属于业务逻辑，应由handler自己决定何时、如何翻译
静态资源（JS/CSS/HTML）里的文案怎么同步i18n
服务端渲染的HTML可以用localizer.Localize注入；但前端JS里写的"Loading..."不会自动变。别试图用Go模板预渲染所有JS字符串——维护成本爆炸。
可行方案：
- 前端用独立i18n库（如
i18next），后端提供/api/i18n/:lang接口返回JSON字典，JS初始化时拉一次缓存 - 服务端在HTML
里注入一个块，内含当前语言的最小翻译映射（如window.I18N = {"common.ok": "OK", "common.cancel": "Cancel"}） - 所有需要多语言的JS组件，统一从
window.I18N或i18next.t取值，不硬编码字符串 - 别让Go模板生成大量JS字符串拼接——
fmt.Sprintf("alert('%s')", localizer.Localize(...))有XSS风险，且无法做前端热更新
语言切换最麻烦的不是读头、也不是加载翻译文件，而是状态同步：用户手动切语言后，页面跳转、API请求头、前端JS字典、服务端session存储的lang字段，这四者必须一致。漏掉任意一环，就会出现按钮是中文、弹窗是英文、API返回406的诡异组合。
