iris国际化需手动集成i18n，关键在于路径键名严格匹配、accept-language解析排序匹配、上下文绑定语言标签、模板t函数闭包捕获ctx、多源语言优先级（url/cookie/header）及重定向保持状态。
用 i18n 包注册语言包时，路径和键名必须严格匹配
Go 生态中 Iris 本身不内置 i18n，实际项目基本都靠第三方 go-i18n 或更轻量的 golang.org/x/text/language + 自定义逻辑。最常用的是 go-i18n 的 i18n 包（注意不是同名但不同的 github.com/nicksnyder/go-i18n v1 版本）。注册失败的常见原因是：
-
LoadTranslationFile指定的路径不存在或权限不足，比如误写成locales/zh.json但实际目录是locales/zh-CN.json - JSON 文件里顶层 key 缺失
language字段，或值不被i18n识别（如写"zh"而非"zh-CN"） - 翻译键（如
"welcome_message"）在模板中调用时拼错，T("welcom_message")少了个l，返回原字符串且无报错
在 Iris 中间件里解析 Accept-Language 并绑定到上下文
Iris 的 Context 没有默认语言字段，必须手动挂载。不能只靠 r.Header.Get("Accept-Language") 粗暴取第一个值——浏览器可能发来 fr-CH, fr;q=0.9, en;q=0.8, de;q=0.7, *;q=0.5，直接截取 fr-CH 可能导致 fallback 失败。
- 用
language.ParseAcceptLanguage解析并按权重排序，再逐个尝试匹配已加载的语言 tag - 匹配不到时，必须显式 fallback 到默认语言（如
language.English），否则T()会 panic 或静默失败 - 把选中的
language.Tag存进ctx.Values().Set("lang", tag)，后续 handler 才能安全读取
模板中调用 T 函数时，参数传递容易漏掉上下文语言信息
Iris 的 HTML 渲染器不自动注入 T 函数，需手动注册。如果只是全局注册一个无参 T，所有请求都会用默认语言渲染——这是多语言站点最隐蔽的 bug。
- 注册函数必须闭包捕获当前
ctx，例如：ctx.ViewData("T", func(key string, args ...interface{}) string { return i18n.T(ctx, key, args...) }) - 若使用
iris.HTML(...).AddFunc全局注册，T无法感知请求级语言，只能返回默认语种翻译 - JSON API 场景下，别忘了在
ctx.JSON前用i18n.Localize单独处理错误消息等字符串字段
切换语言时，Cookie 或 URL 参数要和中间件逻辑对齐
用户点击「切换为日语」，前端通常发请求到 /lang/ja-JP 或设 Cookie lang=ja-JP。但中间件若只看 Header，这个动作就完全失效。
- 中间件应按优先级检查：URL query（
?lang=ja-JP）→ Cookie（lang）→ Header（Accept-Language） - Cookie 必须设置
HttpOnly: false，否则前端 JS 无法写入；同时加SameSite=Lax防 CSRF - 切换后重定向回原页面（
ctx.Redirect(302, ctx.Request().Referer())），避免刷新丢失语言状态
ja-JP，但模板中调用的 T 函数没接收到这个值，结果页面一半日语一半中文。
