关键在于各语言资源独立加载、解析与生效：每个语言包（如zh.json、en.json）须单独加载并绑定专属Intl实例池，DOM解析需显式传入语言码，服务端注入语言应优先级高于localStorage且不可被覆盖，避免状态同步偏差。
怎么让不同语言的配置互不干扰
关键不是“写多份配置”，而是让每种语言的资源加载、生效、切换都走独立通道，避免交叉污染。常见错误是把所有语言包塞进一个对象里，或用同一个 i18n 实例反复调用 setLocale() ——结果是上一个语言的格式化器残留、缓存键冲突、甚至 Intl.NumberFormat 实例复用导致千分位符号错乱。
- 每个语言包必须单独加载、单独解析：
zh.json和en.json不能合并成一个locales.json再按 key 过滤，否则无法做按需加载和 CDN 缓存分离 - 每个语言应有独立的
Intl实例池：比如formatters.zh和formatters.en，不要共用new Intl.DateTimeFormat('en')后又传'zh'去重置 - localStorage 存的是语言码（如
'zh-Hans'），不是配置对象；切语言时清空旧语言的 DOM 标记缓存（比如已翻译过的data-i18n元素列表），否则新语言会跳过部分节点
HTML 中如何隔离多语言模板逻辑
如果你用 html-webpack-plugin 输出多语言 HTML，别在单个插件实例里拼接语言变量——那会导致所有输出共享同一套 templateParameters，一旦某个语言出错，全部崩。正确做法是为每种语言启动独立插件实例，且 template 路径、output filename、inject 配置全隔离。
- 每个实例指定唯一
filename：比如zh/index.html、en/index.html，别用[name].html模板，容易因 webpack chunk name 变动导致路径错乱 -
templateParameters里只传当前语言的数据：不要传{ locales: { zh: {...}, en: {...} } }，而要直接传{ title: '首页', description: '...' } - 禁用
inject: true的自动 script 注入——它会把所有 JS bundle 插到每个 HTML 里，包括未启用语言的 polyfill 或 locale 数据，增大无用体积
为什么不能共用同一套 data-i18n 解析逻辑
表面看 document.querySelectorAll('[data-i18n]') 是通用的，但实际执行时，若多个语言包同时加载、键名重复（如 button.submit 在 zh.json 和 ja.json 里值不同），而解析函数没绑定当前语言上下文，就会随机取到某个语言的值，尤其在异步加载未完成时更明显。
- 解析函数必须带 language 参数：
translateElements(elList, 'zh-Hans')，不能靠闭包或全局变量隐式读取 - 动态插入的 DOM（如弹窗、表格行）必须显式传入当前语言码，不能默认继承页面初始语言——用户可能已在后台切换过语言
- 对
data-i18n-title、data-i18n-placeholder等带后缀的属性，解析逻辑要严格按后缀匹配，不能 fallback 到textContent，否则title显示成 placeholder 文案
服务端注入语言配置时怎么避免客户端覆盖
服务端通过 <script>window.LOCALE = 'zh-Hans';</script> 注入初始语言，但前端如果立刻读 localStorage.getItem('lang') 并覆盖，就破坏了 SSR 一致性。更糟的是，某些 SDK（如 Sentry）会根据 document.documentElement.lang 自动打标，若前后端不一致，监控里看到的语言分布就是错的。
立即学习“前端免费学习笔记（深入）”；
- 优先级链必须硬编码：URL 参数
?lang=ja> localStorage > 服务端注入 >navigator.language，且服务端注入值应写入window.__INITIAL_LOCALE__（带双下划线防误改），而非可变的window.LOCALE - 初始化时立即同步
document.documentElement.lang，但不要修改document.documentElement.dir——方向应由语言码推导（如ar→rtl），而不是由配置项直接赋值 - 切换语言后，发请求更新服务端偏好（如
POST /api/locale），但不要等响应再更新 UI ——先本地生效，失败后再 toast 提示，否则用户感知卡顿
