HTML国际化需联动执行DOM文本更新、lang属性重设、Intl格式器重建、第三方组件locale同步及服务端偏好同步；data-i18n必须覆盖placeholder/title/alt/aria-label等所有可翻译属性，lang须显式设置于各语义化节点而非仅documentElement，语言包加载须校验MIME、处理404、多级fallback并同步服务端。
HTML国际化联动不是“翻译完就完事”，而是语言变更必须触发一连串确定性动作：DOM文本更新、lang属性重设、Intl格式器重建、第三方组件 locale 同步、服务端偏好同步。漏掉任意一环，都会导致视觉、辅助技术、SEO 或功能行为错位。
data-i18n 节点必须覆盖所有可翻译属性，不能只扫 textContent
常见错误是只给 <button data-i18n="btn_submit">提交</button> 标记，却忽略 placeholder、title、aria-label、alt 等属性。结果切换语言后，输入框提示仍是英文，屏幕阅读器读出旧语言，img 的替代文本不更新。
- 每个需翻译的元素至少带一个
data-i18n基础键（如data-i18n="form.email"） - 若含
placeholder，额外加data-i18n-placeholder="form.email_hint" - 同理支持
data-i18n-title、data-i18n-alt、data-i18n-aria-label -
value属性一般不翻译（属用户输入数据），但label文本必须标记，且for与对应input[id]严格匹配
lang 属性必须显式设置在每个语义化容器上，不能靠继承
只改 document.documentElement.lang 是典型半吊子操作。浏览器和屏幕阅读器按元素自身 lang 判定行为，不是查父级。后果包括：title 标签仍被读作旧语言、中文顿号与英文逗号间距错乱、<pre lang="bash"> 因没保留原始 lang 而套用中文字体、alt 文本发音异常。
- 所有含文本的语义化容器（
<h1>、<p>、<section>、<article>）都应显式设lang，值与当前语言包一致 - 已有明确多语言意图的节点（如
<pre lang="bash">、<code lang="zh-Hant">）切换时必须跳过，保留其原始lang -
<script>和<style>节点设lang无效，不要写
接口调用必须工程化编排：加载、校验、降级、同步四步不可少
语言包加载不是简单 fetch('./locales/zh.json') 就完事。没做 MIME 类型校验会静默失败；没处理 404 导致白屏；没 fallback 到备用语言会让用户看到 key 名；没通知服务端则后续 API 错误消息仍是英文。
立即学习“前端免费学习笔记（深入）”；
- 路径统一为
./locales/${lang}.json（如./locales/zh-HK.json），避免硬编码或内联 JSON - 必须用
fetch()+try/catch，内部检查response.ok和response.headers.get('content-type')?.includes('application/json') - 加载失败时 fallback 到次优语言（如请求
zh-CN失败 → 试zh→ 再试en），不能直接报错中断 - 用户手动切换语言后，必须发 POST 到
/api/locale同步偏好，否则服务端后续返回的错误文案、邮件模板等仍为旧语言
最易被忽略的是：动态插入的 DOM（弹窗、AJAX 表格行、innerHTML 拼接内容）插入后不会自动翻译，必须显式调用翻译函数；Intl.DateTimeFormat 实例不能复用，每次语言变更都得新建；window.scrollTo() 必须在语言切换后立即恢复滚动位置，否则页面跳顶。这些都不是“可有可无”的细节，而是决定国际化是否真正可用的分水岭。
