HTML前端国际化核心是语言资源、构建流程、运行时切换三者对齐；需多 HtmlWebpackPlugin 实例输出多语言HTML，语言包应嵌套结构+前缀fallback，禁用i18next后端加载，lang属性须与实际语言严格同步。
HTML 前端工程化中做国际化，核心不是“加个插件”，而是把语言资源、构建流程、运行时切换三者对齐。否则容易出现构建产出错乱、切换语言后文案丢失、新增语言要改七八处配置等问题。
html-webpack-plugin 多语言输出必须配多个实例
单个 HtmlWebpackPlugin 实例只能输出一个 HTML 文件，无法自动按语言生成 index-zh.html、index-en.html 等。必须显式声明多个实例，每个绑定不同语言模板和输出路径：
- 每个实例需独立配置
template（可共用同一模板文件，但通过templateParameters注入不同语言数据） -
filename必须带语言标识，如zh-CN/index.html或en-US/index.html - 若使用
html-loader或自定义 loader 处理模板内t('key')，需确保 loader 能接收当前语言上下文，否则所有输出都渲染成默认语言 - 注意：Webpack 5+ 的
entry不影响 HTML 输出，别误以为配多 entry 就能自动多语言 HTML
语言包 JSON 结构必须支持嵌套与 fallback
扁平的 {"login.title": "登录"} 看似简单，但实际项目中极易冲突、难维护。真正可扩展的结构是模块化嵌套 + 显式 fallback 链：
- 推荐格式：
{"login": {"title": "登录", "submit": "提交"}, "common": {"ok": "确定"}} - fallback 不能只靠
en回退 —— 比如zh-HK应优先 fallback 到zh，再 fallback 到en，这需要在运行时解析navigator.language并匹配前缀 - 构建时若做静态替换（如用
webpack.DefinePlugin注入语言常量），则 fallback 必须在构建阶段完成，运行时无法动态调整 - 避免在 JSON 中写 HTML 片段（如
"tip": "<strong>注意</strong>请确认"），会导致 XSS 风险或 DOM 渲染逻辑耦合
lang 属性与 CSS 伪元素方案仅适合极简场景
用 [lang="zh"] .msg::before { content: "加载中..." } 这类方式看似零 JS，但实际限制极大：
立即学习“前端免费学习笔记（深入）”；
- 仅支持纯文本，无法处理变量插值（如
"已删除 {count} 条记录"） - 无法响应运行时语言切换 —— 改
document.documentElement.lang后，CSS 伪元素不会重计算 - 浏览器对
content的字符长度、换行、特殊符号支持不一致（尤其 Safari 对 Unicode 表情支持滞后） - 调试困难：DOM 中看不到真实文案，只能靠 DevTools 的 Computed 样式面板查，且无法搜索
i18next 浏览器版必须关掉后端加载才适合纯 HTML 工程
很多团队直接引入 i18next，却没意识到它默认启用 backend（即 fetch 加载远程语言包）。这对纯静态 HTML 部署是灾难：
- 本地开发时可能因 CORS 报
Failed to fetch /locales/zh/translation.json - 构建产物若未预置语言包，上线后首屏白屏或文案缺失
- 正确做法：用
i18next.init({ resources: { zh: {...}, en: {...} } })直接注入打包好的语言对象，禁用backend插件 - 若真需要懒加载，应配合 Webpack 的
import()动态导入，并手动调用i18next.addResourceBundle()，而非依赖默认 backend
最易被忽略的一点：HTML 的 lang 属性必须和实际渲染语言严格一致。比如页面用 JS 切到 ja-JP，但 <html lang="ja"> 没同步更新，会导致屏幕阅读器读错、SEO 识别偏差、CSS 伪元素失效 —— 这个属性不是装饰，是规范强制要求的语义标记。
