用 data-i18n 属性标记可翻译元素，JS 仅更新 textContent、placeholder、title、aria-label 等文案属性，避开 value/checked 等状态属性，确保用户输入不丢失；语言包为多层键值对象，支持 zh-CN/zh-TW/en-US 等精细化映射，通过 fetch 动态加载 JSON，避免硬编码与 innerHTML 风险。
如何用 data-* 属性 + JavaScript 实现语言包切换
多语言表单不靠框架也能快速落地，核心是把文案抽成键值对，用 data-i18n 标记需要翻译的元素，再用 JS 按需替换文本内容。避免硬编码、不依赖后端渲染，适合静态页或轻量 SPA。
常见错误是直接改 innerHTML 导致表单控件状态丢失（比如用户已输入但切语言后清空），所以只更新 textContent 或 placeholder 等属性，避开 value 和 checked。
- 语言包用纯对象组织，例如：
{ en: { login: "Sign in", email: "Email address" }, zh: { login: "登录", email: "邮箱地址" } } - 切换时只遍历带
data-i18n的元素，查键匹配，更新textContent、title、placeholder、aria-label四类属性 - 按钮文字、label 文本、提示信息都支持，但
select的option需单独处理——它们没有data-i18n，得用data-i18n-options标记父select，再批量重写option.textContent
HTML 结构怎么写才方便后续维护
关键不是“怎么写漂亮”，而是“怎么写让 JS 能精准定位并安全更新”。所有可翻译节点必须有明确标识，且不破坏语义结构。
错误写法：<button>提交</button> —— 没标识，JS 找不到；或者 <span id="btn-submit"></span> —— 依赖 ID，易冲突、难批量。
立即学习“前端免费学习笔记（深入）”；
- 统一用
data-i18n="login_btn"标记需要翻译的元素，键名语义清晰，不带语言前缀 - label 关联 input 时，把
data-i18n放在<label>上，不要放for属性里 - input 的 placeholder 写成
placeholder="Email address" data-i18n-placeholder="email_placeholder"，分离原始值与键名，避免初始渲染错乱 - 禁用
innerHTML更新含子节点的容器（如带 icon 的按钮），改用data-i18n-text+data-i18n-attr组合控制
切换语言时如何保留用户已填内容
最常被忽略的一点：切语言 ≠ 重置表单。用户填了邮箱、选了城市、勾了协议，这些状态必须原样保留，否则体验崩坏。
根本原则是——JS 只动文案，不动状态。表单控件的 value、checked、selected、disabled 等状态属性一律跳过。
- 遍历所有带
data-i18n的元素时，显式过滤掉input、textarea、select、button的value属性（除非你明确要改按钮文字） - placeholder 更新安全，因为不影响
value；但title和aria-label可以放心更新 - 如果用了自定义下拉组件（非原生
select），需额外监听其内部文案容器，用相同规则处理 - 切换后触发
dispatchEvent(new Event('i18n:changed'))，方便外部逻辑响应（比如重绘日期选择器里的月份名）
中文简体/繁体/英文共存时的路径陷阱
别用 zh 当键名直接覆盖所有中文场景。简体（zh-CN）、繁体（zh-TW）、英文（en-US）的文案差异真实存在，比如“登录” vs “登入”，“邮箱” vs “电邮”。
语言检测不能只看 navigator.language，它可能返回 zh-Hans-CN 或 zh-Hant-TW，需 normalize 后映射到你的语言码表。
- 预设语言码映射表：
{ "zh-CN": "zh", "zh-TW": "zh-Hant", "en-US": "en", "en-GB": "en" }，避免键名爆炸 - 用户手动切换时，存的是短码（
zh/en），但加载语言包时优先匹配完整码（zh-CN）， fallback 到短码 - 路径中别用
/lang/zh/这种硬编码，静态资源走同一路径，靠 JS 加载对应 JSON 文件，例如fetch(`/i18n/${lang}.json`) - 注意 HTTP 缓存：JSON 语言文件加
Cache-Control: immutable，但版本变更时强制更新 URL（如i18n/en.json?v=2.1.0）
实际跑起来最麻烦的不是翻译本身，是那些没被 data-i18n 标记却该翻译的角落——比如 JS 动态插入的提示框、第三方组件里的按钮、甚至 SVG 的 <title>。留个 checklist 比写个大而全的方案更管用。
