data-i18n+JSON方案扩展性差在无法原生支持复数、日期格式、RTL、动态文案及HTML安全转义；i18next通过可插拔模块（如http-backend、languagedetector、react-i18next）解决工程化痛点，但落地前需对齐语言包结构、lang属性同步和动态内容统一入口。
data-i18n + JSON 方案扩展性差在哪
纯 data-i18n + 手写 JS 翻译函数在小项目里跑得稳，但一加需求就露馅：复数（如 “1 file” / “2 files”）、日期格式（Intl.DateTimeFormat）、RTL 布局切换、动态插入的弹窗文案、表单验证错误提示——这些全得自己补轮子。更麻烦的是，语言包里一旦出现 HTML 片段（比如带 <strong> 的提示），直接 innerHTML 赋值有 XSS 风险，手动转义又容易漏。
i18next 是怎么解决工程化痛点的
i18next 不是“多一个库”，而是把国际化拆成可插拔模块来管：
- 用
i18next-http-backend替代手写fetch('./locales/en.json')，自动重试、缓存、fallback 链都内置好了 - 靠
i18next-browser-languagedetector综合读取navigator.language、localStorage、cookie、URL 参数，比单靠一个更靠谱 -
react-i18next或i18next-svelte提供组件级t()函数，避免全局遍历 DOM；服务端渲染时还能预加载语言包，不闪屏 - 复数规则、上下文（如 “male/female/other”）、命名空间（
form:submitvscommon:cancel）全靠配置开，不用改业务逻辑
为什么别急着上 i18next？先看这三件事
很多团队踩坑不是因为库不好，而是没对齐基础约束：
- 语言包必须扁平结构或严格按命名空间嵌套——
i18next默认不递归合并，zh.json里漏了"errors.required"，它不会去common.json找，直接留空 - HTML 中带
data-i18n的元素，如果用了i18next的init({ interpolation: { escapeValue: false } })，就得确保所有翻译值都来自可信源，否则t('welcome_html')返回"Hello <strong>{{name}}</strong>"就可能被注入 - 切换语言后，
document.documentElement.lang得手动同步更新——i18next不管这个，但屏幕阅读器、CSS:lang()、字体回退全靠它，漏掉就等于白切
第三方库和原生方案混用的关键边界
工程里常要保留部分手写逻辑，比如表单验证消息来自后端 API，或某块内容必须走机器翻译。这时候得守住两条线：
立即学习“前端免费学习笔记（深入）”；
- 所有由
i18next管理的 key 必须进统一语言包，别在 JS 里拼字符串再传给t()，否则无法提取、无法翻译协作 - 动态内容（如用户昵称插入文案）用
t('welcome', { name: userName })，别用模板字符串`欢迎 ${userName}`——后者没法做复数、无法抽离、不能 RTL 适配 - 如果某页用
i18next，另一页还用原生data-i18n，两个系统各自维护语言状态，localStorage里存的键名、格式、fallback 逻辑稍有不一致，切换语言就会出现部分文字不变、部分乱码
lang 属性是否随切换实时更新、动态内容是否全部走翻译函数入口——这些细节不拉齐，换再强的库也撑不住。 
