Fiber 本身不内置国际化支持，需自行组织语言包、中间件和上下文传递，通过启动时加载 JSON/Go map 语言数据到全局变量，用 ctx.Locals 或中间件注入请求上下文，按路径前缀、Accept-Language 头或 lang 查询参数识别偏好，并注意 Content-Language 响应头、状态保持、安全 Cookie 设置及 CDN 多语言缓存分离。
Fiber 本身不内置国际化（i18n）支持，也没有类似 vue-i18n 或 react-i18next 那样的官方插件。要实现多语言切换，得靠你自己组织语言包 + 中间件 + 上下文传递，再配合路由或请求头识别语言偏好。
怎么在 Fiber 中挂载语言包和翻译函数
核心是把语言数据提前加载进内存，然后通过 ctx.Locals 或自定义中间件注入到每个请求上下文里。
- 语言包建议用纯 JSON 或 Go map，避免运行时动态 import（Go 不支持）
- 推荐结构：
map[string]map[string]string，比如langs["zh"]["login.title"] = "登录" - 不要在 handler 里反复读文件或解析 JSON —— 启动时一次性加载并缓存到全局变量或
fiber.App的Settings里 - 翻译函数最好封装成闭包，接收
*fiber.Ctx和 key，自动取当前语言再查表
如何从请求中识别用户语言偏好
常见来源有三个：URL 路径前缀（如 /zh/login）、Accept-Language 请求头、或客户端传来的 lang 查询参数。优先级需明确，否则切换逻辑会混乱。
- 路径前缀最可控，适合 SEO 和显式切换，但需要配置带语言前缀的路由组（
app.Group("/zh")） -
Accept-Language头由浏览器发送，但可能不准（比如公司统一代理改写了 header） - 查询参数（如
?lang=ja）适合手动触发切换，但要注意重定向后保留参数，否则刷新就丢语言了 - 别忘了设置响应头
Content-Language，辅助浏览器和爬虫理解当前响应语言
切换语言时怎么保持状态不丢失
用户点“切换为英文”后，你不能只改 ctx 的语言字段就完事——页面跳转、表单提交、API 请求都得带上新语言上下文，否则下个请求又回退到默认语言。
- 前端发请求时，统一加
langheader 或 query 参数，后端中间件优先从此处取值 - 如果用模板渲染（
ctx.Render），确保 layout 模板里语言切换链接带当前路径 + 新 lang 参数，而不是写死/en/xxx - Session 或 Cookie 存储用户首选语言时，注意有效期和作用域；别用
SetCookie直接写裸字符串，要用fiber.Cookie结构体控制HttpOnly、SameSite等安全项 - API 场景下，前端必须每次请求都传语言标识，服务端不依赖 session 做语言判定——无状态才可靠
为什么 fiber.New() 的 Settings 不适合存语言数据
fiber.Settings 是应用级配置，不是运行时数据容器。它不提供并发安全的读写，也不支持按请求隔离。把语言映射表塞进去，会导致所有请求共享同一份 map，一旦某个请求修改了它（比如热更新语言包），其他请求立刻受影响。
- 正确做法：语言包放全局常量或初始化后的
var langs = map[string]map[string]string{...} - 请求级语言标识存在
ctx.Locals("lang")，这是 fiber 为每个请求单独分配的 map，线程安全 - 如果真要热更新语言包，得用
sync.RWMutex包裹读写，且更新操作应走管理接口（如POST /admin/i18n/reload），而非运行时随意赋值
实际中最容易被忽略的是：语言切换后，前端资源（JS/CSS）的 CDN 缓存是否也按语言做了分离？ 比如 i18n.js?lang=zh 和 i18n.js?lang=en 如果共用同一个 URL，CDN 可能返回旧语言的缓存内容。这个问题不在 Fiber 控制范围内，但线上出 bug 时往往最先被怀疑是后端问题。
