lang属性仅声明内容语言，不依赖浏览器首选项；其值必须与实际文本语言严格一致，否则导致翻译误判、语音朗读错误、SEO降权等连锁失效。
lang 属性不读取也不依赖浏览器语言首选项，它只声明内容本身的语言；浏览器翻译功能是否触发、用什么语音引擎朗读，取决于 lang 值与内容实际语言是否一致，而非用户设置的“首选语言”。
lang 属性和浏览器语言设置完全无关
很多人误以为把 lang="zh-CN" 改成 lang="ja-JP" 就能让 Chrome 自动按日语偏好翻译——其实不是。浏览器语言首选项（如 Chrome 设置里的“Languages”列表）只影响：chrome://settings/languages 里选的界面语言、新标签页推荐内容、部分扩展行为；它不会覆盖或修正页面上明确声明的 lang 值。
真正起作用的是：<html lang="zh-CN"> 这个值告诉浏览器“这页内容是简体中文”，后续所有链路（语音合成、断词、字体 fallback、拼写检查）都基于此做决策，和用户浏览器设了 5 种语言毫无关系。
- 用户浏览器设了 en-US + fr-FR + de-DE，但页面
lang="zh-CN"→ 仍按中文加载 TTS 引擎，不自动切法语朗读 - 用户没装日语语音包，页面却写了
lang="ja-JP"→ VoiceOver 或 NVDA 可能静默降级为英语发音，不报错也不提示 - Chrome 翻译按钮是否出现，只看两个条件：①
<html lang>是否合法且非空；② 页面实际文本语言与该值是否明显偏离（比如lang="en-US"但满屏汉字）
浏览器怎么判断“该不该翻译”
Chrome 的翻译逻辑是内容驱动，不是设置驱动。它会做两件事：
立即学习“前端免费学习笔记（深入）”；
- 先提取页面可见文本（跳过
<script>、<style>、aria-hidden="true"内容），用统计模型估算主导语言 - 再比对
<html lang="...">声明值：若一致（如内容是中文 +lang="zh-CN"），默认不提示翻译；若明显不一致（如内容是英文 +lang="zh-CN"），才显示“此页为英文，是否翻译为中文？”
注意：lang 不是开关，只是声明。你写 lang="en-US" 但页面全是阿拉伯文，Chrome 依然会检测出阿拉伯语，并可能提示“是否翻译为你的首选语言（比如中文）”。
为什么改了浏览器语言首选项，页面朗读还是错的
因为屏幕阅读器（NVDA、VoiceOver、JAWS）在解析 HTML 初始字符串时，就锁定了 document.documentElement.lang 的值。它不关心你系统语言设成西班牙语，也不轮询浏览器设置——它只信 HTML 根标签那一行。
- 页面输出时
<html lang="en-US">，哪怕用户系统是中文，VoiceOver 也会尝试用英语 TTS 读中文词，“北京”变成 /peiˈdʒɪŋ/ 而非 /běi jīng/ - 切换浏览器语言后刷新页面，如果服务端没重写
lang值，<html lang="en-US">仍然存在 → 读屏行为不变 - JS 动态执行
document.documentElement.lang = "zh-CN"对已激活的朗读会话基本无效，必须强制重载或触发根节点重读（如document.title = document.title）
多语言站点中 lang 和用户首选项的真实协作方式
真正健壮的做法，是让服务端或 SSR 框架根据用户请求头（Accept-Language）或登录态，动态输出匹配的 lang 值，而不是靠前端 JS 去“适配”浏览器设置。
- Next.js：在
app/layout.tsx中用localeprop 渲染<html lang={locale}>，确保首屏 HTML 正确 - PHP/Nginx：根据
Accept-Language: zh-CN,zh;q=0.9头，模板中插入<html lang="zh-CN"> - 纯静态站：无法动态响应，必须为每种语言建独立路径（
/zh/、/en/），并在对应 HTML 中硬编码lang
关键点在于：lang 是内容属性，不是用户配置镜像。它必须与真实文案语言严格一致，否则从可访问性到 SEO 全链路都会悄悄失效——而这种失效往往没有控制台报错，只有用户听错了、搜不到了、翻译翻串了，才后知后觉。
