应采用“模块_功能_状态”三级命名法，如login_form_email_label、profile_save_success_toast，避免泛化名和语言词；键名须中立、可定位UI位置，新增前全局搜索防重复，模板片段加前缀，CI校验键一致性，并同步更新lang属性确保辅助技术正确读取。
怎么分配data-i18n键名才不会冲突
多人协作时，键名重复或结构混乱是翻译失效的第一诱因。键名不是随便起的，它得能定位到具体 UI 位置，且不依赖 DOM 结构变动。
- 用「模块_功能_状态」三级命名，比如
login_form_email_label、profile_save_success_toast，避免title或btn_ok这类泛化名 - 禁止在键名里塞语言词（如
zh_home），语言包本身已按语言隔离，键名必须中立 - 新增文案前，先 grep 全局搜索是否已有同名键；CI 流程里加脚本校验所有 JSON 文件键名一致性
-
template中的片段（如弹窗、卡片）要带前缀，例如modal_delete_confirm_title，否则和主页面键名易撞车
如何让新成员快速上手翻译标记规范
新人常漏标 placeholder、title、aria-label，只改了 textContent，结果表单提示还是英文，屏幕阅读器读错。
- 提供一份最小检查清单：每个可交互元素至少要覆盖
data-i18n+ 对应属性后缀（data-i18n-placeholder、data-i18n-title等） - 把常见遗漏点写成 ESLint 插件规则，例如检测
<input>有placeholder但无data-i18n-placeholder - 模板文件（
<template>）必须附带注释说明：「克隆后需手动调用translateNode()，否则data-i18n不生效」 - 禁止在
<script>、<style>、<pre>内写data-i18n——这些节点不渲染文本，加了等于没加
语言包合并与冲突怎么自动化处理
多人同时改 en-US.json 和 zh-CN.json，merge 时容易丢键、留空值、字段错位，导致某语言整块空白。
- 每个语言文件必须扁平结构，禁止嵌套对象；所有文件字段顺序一致，用工具（如
json-sort）自动标准化 - PR 提交前强制运行 diff 脚本：比对新增键是否在所有语言文件中都存在，缺失则报 CI 错误
- 空值不是 bug，而是明确占位符——
"nav_settings": ""表示“暂未翻译”，比直接删掉键更安全 - 加载失败 fallback 必须走两级：先试
zh-HK，再试zh，最后兜底en-US；不能只靠根语言码硬切
动态内容插入后怎么保证翻译不漏
AJAX 加载的列表项、fetch() 拉的弹窗、template 克隆的卡片——这些节点不会被初始翻译函数扫到，一刷新就回英文。
立即学习“前端免费学习笔记（深入）”；
- 封装
renderAndTranslate(htmlString)工具函数：先DOMParser解析，再translateNode()遍历，最后 append - 所有异步插入入口统一走这个函数，而不是直接
innerHTML = ... -
translateNode()必须支持传入任意节点（不只是document.body），且跳过value、data等非展示属性 - 切换语言时，不仅要重刷当前视图，还得遍历所有已挂载的动态模块容器，主动触发它们的
retranslate()
lang 属性同步——哪怕文案全对，<p lang="en"> 没跟着语言切换更新，屏幕阅读器照样读错音。 
