Buffalo内置国际化（buffalo.Locale）是编译期绑定，所有语言包打包进二进制，无法运行时按需加载、CDN托管或动态更新；必须结合i18next等外部库+自定义HTTP路由（如/app.GET("/i18n/{lang}.json", I18nHandler)）实现真正的按需加载。
Buffalo 框架本身不内置多语言按需加载能力，必须结合外部 i18n 库（如 i18next 或 go-i18n）+ 自定义 HTTP 后端 + 路由/中间件控制才能实现真正的「按需动态加载」。
为什么不能直接用 Buffalo 的 buffalo.Locale 或 buffalo.Translate 实现按需？
Buffalo 的内置国际化支持（buffalo.Locale）是编译期绑定的：所有语言文件在构建时被读取、解析并注入到二进制中。这意味着：
- 所有语言包都会被打包进最终可执行文件，无法按用户请求动态拉取
- 新增语言需重新编译部署，不满足「运行时切换」和「CDN 托管语言资源」需求
- 不支持命名空间拆分、fallback 链、异步加载失败重试等现代 i18n 场景
推荐方案：用 i18next-http-backend + 自定义 Go 后端路由
核心思路是绕过 Buffalo 的模板层国际化，改用前端 JS（如 React/Vue）通过 i18next 加载语言资源，而 Go 后端只负责按需提供 JSON 接口 —— 这才是真正的「按需」。
关键实操点：
Buffalo框架 1.0.1
下载
Buffalo框架 1.0.1 版本源码包下载，适合需要错误处理改进、依赖更新、render.Download 注释和 request logger 调整的 v1 项目。
- 在 Buffalo 的
app.go中注册一个动态路由：app.GET("/i18n/{lang}.json", I18nHandler) -
I18nHandler函数根据ctx.Param("lang")读取对应文件（如./locales/en-US.json），校验合法性（防路径遍历），设置Cache-Control: public, max-age=31536000 - 前端初始化
i18next时配置backend.loadPath为/i18n/{{lng}}.json，并启用allowMultiLoading: true支持命名空间 - 语言码需标准化处理（如浏览器传
zh-CN，后端 fallback 到zh或en）
如果坚持在服务端渲染中做按需（如 HTML 模板直出）
这会牺牲「真正按需」的灵活性，但适合简单场景。需注意：
- 不能依赖
buffalo.Locale的全局加载，而应在每个请求中按Accept-Language或 query 参数（?lang=ja-JP）动态读取文件：ioutil.ReadFile(fmt.Sprintf("./locales/%s.json", lang)) - 必须手动解析 JSON 并注入到模板上下文（
c.Set("translations", data)），再在.html.plush中用{{ translations.homepage.title }}访问 - 务必加内存缓存（如
sync.Map），避免每次请求都读磁盘；同时限制允许的语言白名单，防止恶意参数导致文件读取失败或 OOM - 无法利用浏览器缓存，所有翻译内容随 HTML 一起传输，首次加载体积仍大
真正按需的关键不在框架选择，而在资源交付链路的设计：语言包必须是独立 HTTP 资源，能被 CDN 缓存、能单独更新、能按需请求。Buffalo 只是那个暴露接口的「门卫」，别让它背负翻译解析的职责。
