必须在服务端或构建时确定lang值，不能靠navigator.language在客户端动态设置——否则屏幕阅读器已加载完毕，语音引擎不会重载，CSS :lang()也不重匹配。
必须在服务端或构建时确定 lang 值，不能靠 navigator.language 在客户端动态设置根节点语言——否则屏幕阅读器已加载完毕，语音引擎不会重载，CSS :lang() 也不重匹配。
为什么不能用 navigator.language 直接设 document.documentElement.lang
浏览器和读屏软件（如 NVDA、VoiceOver）只在解析 HTML 字符串的最早阶段读取 <html lang="zh-CN">。JS 执行时 DOM 已构建完成，此时改 document.documentElement.lang：
- 对已激活的语音合成引擎无效——它不会切换 TTS 引擎，仍按旧语言规则切音节、读多音字（比如把“行”固定读成 háng）
- CSS 中的
:lang(zh)伪类不会重新计算，导致中文字体回退、避头尾等排版规则失效 - Chrome 翻译按钮可能不出现，或错误触发（比如页面全是中文却提示“翻译成日语”）
真正有效的地区感知设置方式
要让 lang 值反映用户实际地区偏好，必须在 HTML 首屏生成阶段注入，而不是 JS 运行时补救：
- 服务端渲染（SSR）：根据请求头
Accept-Language解析出最匹配的 BCP 47 值（如zh-TW、en-GB），直接写入模板中的<html lang="..."> - 静态站点生成（SSG）：为不同地区语言产出独立 HTML 入口文件，如
/zh-tw/index.html写<html lang="zh-TW"> - Next.js：
app/layout.tsx中用<html lang={locale}>，locale来自路由参数或中间件解析 - Nuxt：用
useLocaleHead()，确保lang出现在初始 HTML 字符串里
navigator.language 只能用于降级兜底，不能当主逻辑
如果必须走纯前端方案（无 SSR/SSG），navigator.language 可作为 fallback 依据，但仅限于：
立即学习“前端免费学习笔记（深入）”；
- 从
navigator.language提取主语言码（如"zh-CN"→"zh"），再查本地语言包是否存在对应键；不存在则回退到en-US - 配合
localStorage.getItem('preferred-lang')优先读用户上次选择，而非盲目信navigator.language - 设置
document.documentElement.lang的同时，必须同步更新所有文案、字体加载策略、甚至hreflanglink 标签——否则各链路会错位
地区码选错比不写还危险
写 lang="zh" 或 lang="en" 看似省事，但会导致：
- iOS VoiceOver 跳过中文 TTS，把“长”读成 /tʃæŋ/
- Google Search Console 报“未指定语言”，影响多语言站点 hreflang 联动
- CSS
font-family: "PingFang SC", "Hiragino Sans GB"在lang="ja"下才启用日文字体回退，lang="zh"不触发
真正该用的值只有明确的 BCP 47 组合：zh-CN、zh-TW、en-US、fr-FR——大小写、连字符、顺序全不能错，下划线（zh_CN）或全大写（ZH-CN）均被静默忽略。
