lang属性必须写在html标签上，因为根元素的lang是浏览器、搜索引擎和屏幕阅读器识别页面主语言的唯一可靠依据；局部元素的lang仅影响自身，需显式声明且符合bcp 47标准。
lang属性必须写在html标签上，否则浏览器不认
根元素html的lang属性是浏览器、搜索引擎和屏幕阅读器识别页面主语言的唯一可靠依据。只给某个div或p加lang，对SEO、字体回退、自动翻译提示几乎没影响——它们根本不会扫描这些局部节点来决定整页基调。
常见错误现象：
- 页面主体是中文，但
html没设lang，Chrome 自动翻译成英文再翻回中文，语义错乱 - SPA 切换语言后只改了
document.body或某个容器的lang，结果语音朗读仍用旧语种，标点间距也不对
实操建议：
- SSR 页面：服务端渲染时，根据
Accept-Language头动态写入 - SPA 页面：在语言切换钩子中执行
document.documentElement.lang = "ja-JP"，别只改 state 或 class - 静态页：每个语言版本单独一份 HTML，
html标签硬编码对应值，避免 JS 注入延迟导致闪动
局部多语言内容必须显式写lang，不能靠继承
浏览器不会自动推断「这段英文是引用」「这行日文是代码注释」——它只认你明写的lang。不加，就全按根语言处理，后果是语音朗读错、拼写检查失效、字体 fallback 异常（比如日文混排时用中文字体显示假名）。
使用场景举例：
- 中文文档里嵌一段法语引文：
<blockquote lang="fr">Je suis français.</blockquote> - 技术文档中夹
<code lang="en">useState，可触发 IDE 插件英文高亮 -
<pre class="brush:php;toolbar:false;" lang="bash">curl -X POST</pre>——lang="bash"虽非标准语言码，但被语法高亮工具和浏览器识别为代码上下文
容易踩的坑：
- 给每个单词都加
lang：DOM 体积增大，可访问性树构建变慢，得不偿失 - 误以为
lang="ja"足够：iOS VoiceOver 某些版本会降级为英语发音，lang="ja-JP"更稳妥 - 后端返回
zh_ch或ZH-CN，前端没转成小写+连字符，导致lang值非法被忽略
切换语言时必须同步更新所有lang属性，不只是根节点
只改document.documentElement.lang，对已渲染的子元素完全无效。屏幕阅读器、浏览器字体引擎、拼写检查器，全按**每个元素自身的lang值**工作，不是看父级继承来的。
实操要点：
- 切换前，先遍历所有带
lang属性的元素（如<p lang="en"></p>、<pre class="brush:php;toolbar:false;" lang="bash"></pre>），把它们的lang也批量更新 - 除非明确要保留原语言（比如一段固定英文术语），否则别漏掉任何一处
- 更新 DOM 前用
getComputedStyle记录滚动位置，否则页面可能跳回顶部
性能提示：用document.querySelectorAll("[lang]")比递归遍历快，且能精准命中所有已声明语言的节点。
lang值必须符合 BCP 47 标准，否则等于没写
浏览器和辅助技术只认标准格式，zh-CN可以，zh_CN、chinese、zh-hans（无地区标识）会被忽略或触发 fallback，甚至静默失败。
关键判断点：
- 地区子标签不是“用了更好”，而是“不用会出错”：简繁混排必须用
zh-CN/zh-TW，否则「软件」vs「軟體」断行错、字体 fallback 错 - 美式/英式英文差异（
color/colour）影响输入法候选词和 spellcheck，得用en-US/en-GB - 日期/货币格式由
Intl.DateTimeFormat等 API 依赖lang值解析，ja-JP和ja行为不同
最稳妥做法：后端返回语言码后，前端强制标准化为小写+连字符格式，例如zh_cn → zh-CN，EN-US → en-US。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
