html本身无i18n运行时能力，必须依赖构建工具+模板+轻量js接管实现多语言；仅靠lang属性不触发翻译，维护多份html会导致模板重复与动态内容失效。
直接说结论：HTML 本身没有国际化（i18n）运行时能力，所谓“HTML 工程化实现高效国际化”，本质是用构建工具 + 模板机制 + 运行时轻量接管，在 HTML 文件生成阶段注入语言资源，而非靠 或纯静态 HTML 标签解决多语言问题。
为什么不能只靠 lang 属性或 HTML 多份副本？
lang 只影响语义、字体回退和部分 ARIA 行为，不触发文本翻译；维护多份 HTML（如 index-zh.html、index-en.html）会导致模板重复、逻辑不同步、CI/CD 膨胀——尤其当页面含动态区块（如用户昵称、实时状态）时，纯静态复制立刻失效。
真正要解决的是：同一份 HTML 源码，能按需产出不同语言的最终 HTML，且支持运行时语言切换（如用户点按钮切语言）。
推荐链路：Vite + i18next + HTML 模板预编译
主流工程化方案中，Vite 的 transformIndexHtml 钩子 + i18next 的后端集成能力，比 Webpack 的 html-webpack-plugin 更轻量可控。关键不是“把 i18next 加进 HTML”，而是让构建过程读取语言包，把翻译结果提前写入 HTML 字符串。
- 语言资源统一存为 JSON（如
locales/zh-CN/common.json），键名保持扁平（避免嵌套路径导致模板难写） - 在 Vite 插件中用
fs.readFileSync读取对应 locale 的 JSON，注入到index.html的<script></script>块里，作为全局变量window.I18N_DATA - HTML 模板里用占位符，例如
<h1 data-i18n="home.title"></h1>，构建时由插件替换为真实文本（或留空，交由运行时接管） - 若需运行时切换，保留
i18next初始化逻辑，但禁用其默认的异步加载，改从window.I18N_DATA读取，避免二次请求
vite-plugin-i18n-html 的坑：它不处理动态内容
这个插件能自动替换 data-i18n 属性值，但只在构建时生效。如果页面有 JS 动态插入的 DOM（比如 document.createElement('div').textContent = 'Loading...'），它完全无感——这类文本必须走 i18next.t() 显式调用。
常见错误现象：data-i18n 翻译正常，但弹窗提示、表单校验信息、AJAX 错误提示仍是英文，因为它们不在初始 HTML 中。
- 所有 JS 中出现的字符串，必须通过
i18next.t('form.required')获取，不能硬编码 - 避免在模板字符串里拼接翻译结果，例如
`${t('error')}：${code}`—— 会破坏 ICU 格式（如复数、性别）的解析 - Vite 构建时若未指定
--mode zh-CN，插件默认 fallback 到en，但开发服务器不会自动重载语言，需手动刷新
SEO 和 SSR 场景下，lang 和 hreflang 仍需手写
搜索引擎依赖 和 <link rel="alternate" hreflang="en" href="/en/"> 识别语言版本。工程化流程可以自动生成这些标签，但必须确保：
- 每个语言输出的 HTML 文件路径与
hreflang的href完全一致（如/zh/对应zh-CN，不能写成/zh-cn/） -
lang值需符合 BCP 47 标准（zh-Hans≠zh-CN，前者是简体中文书写规范，后者是国家地区，搜索引擎视为不同语言） - 若用 SSG（如 VitePress），需确认其
build命令是否对每个 locale 单独执行，否则hreflang会漏掉某些语言
最易被忽略的一点：语言切换按钮的 URL 必须带完整路径前缀（如从 /zh/user 切到 /en/user），而不是仅改 hash 或 query，否则搜索引擎无法索引目标页。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
