document.documentElement.lang 仅是 DOM 属性，无法真正切换页面语言，因浏览器和辅助技术在解析阶段已锁定 lang 值，后续 JS 修改无效。
只改 document.documentElement.lang 无法真正切换页面语言——屏幕阅读器不重载、Chrome 翻译按钮不出现、SEO 无感知，它只是个 DOM 属性值，不是运行时语言开关。
为什么 document.documentElement.lang = "en-US" 失效
浏览器和辅助技术（NVDA、VoiceOver）在 HTML 解析阶段就读取 <html lang="zh-CN">，之后 JS 修改该属性对已激活的朗读会话、翻译状态、搜索引擎抓取完全无效。
- 现象：切换后 VoiceOver 仍用中文引擎读英文文案，“API”被硬读成“阿皮”
- 现象：
:lang(en)CSS 规则不重新匹配，字体或避头尾样式失效 - 现象：Google Search Console 持续报“未指定语言”，hreflang 与实际 lang 不一致导致多语言索引错乱
- 根本原因：DOM 已渲染完成，
lang不是响应式属性，没有 MutationObserver 级别的语义监听
服务端渲染（SSR）项目必须首屏注入
Next.js、Nuxt、Remix 等框架中，lang 必须由服务端在初始 HTML 响应中输出，不能等客户端 hydration 后再设。
- Next.js App Router：在
app/layout.tsx中写<html lang={locale}>，locale来自路由参数或 cookie - Nuxt：用
useLocaleHead({ lang: 'zh-CN' })，确保生成的<html>标签带正确值 - PHP/模板引擎：直接在 HTML 模板里插值，如
<html lang="= htmlspecialchars($lang, ENT_QUOTES) ?>">，防 XSS - 切忌：在
useEffect或onMounted里执行document.documentElement.lang = ...—— 首屏已定型
纯前端 SPA 切换语言的两种可行路径
没有 SSR 能力时，靠 JS “打补丁”本质是妥协方案，但有且仅有两个相对可靠的做法：
立即学习“前端免费学习笔记（深入）”；
- 整页刷新：
window.location.href = '/en-US/'（对应静态生成的独立 HTML 文件），最稳妥，兼容所有辅助技术 - 重写 outerHTML：
document.documentElement.outerHTML = newHtmlString，需完整重建整个<html>字符串（含<head>内所有 meta、link、script），否则 ARIA 缓存残留、document.title不同步、第三方脚本状态丢失 - 绝对避免：
document.documentElement.setAttribute('lang', 'en-US')或document.body.lang = 'en-US'—— 这两类操作对可访问性链路零效果 - 若必须局部更新，至少同步触发
document.title = document.title（空赋值），强制部分读屏软件重读根节点，但成功率低且不稳定
表格、代码块、引文等局部内容怎么同步更新
<html lang="zh-CN"> 只定义主语言，不覆盖子元素。用户切换语言后，所有显式声明 lang 的节点必须一并更新，否则外文内容仍被按原语言规则处理。
-
<td lang="en">API</td>→ 切到日语页时，应改为<td lang="en">API</td>（保留英文术语）或<td lang="ja">API</td>（若已本地化） -
<pre lang="bash">curl -X POST</pre>→lang应保持"bash"，不是语言代码；若内含注释如# 初始化计数器，则需包裹为<span lang="zh-Hans">初始化计数器</span> -
<blockquote lang="fr"></blockquote>→ 若该引文不随页面语言切换，就不用动；若需本地化，则替换整个内容并更新lang - 别漏掉
<meta name="description" content="...">和<title>的文本内容，它们的语言上下文也依赖lang声明
真正难的不是写对一个 lang="zh-CN"，而是让每个动态插入的节点、每段第三方 SDK 渲染的文案、每个 iframe 里的子页面，都带着准确的语言上下文被解析——这需要从构建时、请求链路、组件封装三个层面统一约束，而不是靠一次 JS 赋值解决。
