lang属性必须写在标签上，是浏览器、搜索引擎和辅助技术识别页面语言的第一依据；局部切换需用内联lang显式声明，且值须符合bcp 47标准，如zh-cn、en-us。
lang 属性写在 标签上，不是“可有可无的装饰”，而是浏览器、搜索引擎和辅助技术识别页面语言的**第一依据**。没它，中文页面可能被当成英文朗读，SEO 降权，字体回退错乱，拼写检查失效——这些都不是理论风险，是真实发生的故障。
为什么必须设在
根元素的 lang 是整个文档的默认语言源头，具有继承性：所有子元素在未显式声明 lang 时，都按它来解析。
- 屏幕阅读器靠它决定发音规则，比如 “lead” 在英语里读 /liːd/（动词）还是 /led/（名词），中文混排英文术语时若根
lang错了，整段语音输出会失真 - Chrome 和 Safari 的内置翻译功能，优先读取
而非 HTTPContent-Language头或页面内容统计结果 - CSS 中的
:lang(en)伪类、quotes属性、某些字体回退链（如font-family: "PingFang SC", "Helvetica Neue", sans-serif）都依赖根语言判断渲染逻辑
lang 值怎么写才合法？
必须用 BCP 47 标准格式，不是随便填个字符串就行。常见错误包括：zh_CN、chinese、en-us（小写连字符不推荐）、zh-Hans-CN（过度冗余）。
- 简体中文用
zh-CN或更推荐的zh-Hans（不绑定国家，适配港澳台简体场景） - 美式英语用
en-US，英式用en-GB；只写en也合法，但丢失地域习惯（如日期格式、标点间距） - IANA Language Subtag Registry 是唯一权威来源，别信网上搜到的“常用代码表”——比如
pt-BR正确，bra或portuguese-br全错
局部语言切换为什么不能只改 document.documentElement.lang？
JS 动态修改 document.documentElement.lang = 'ja' 只影响根节点及其后续新插入的子元素，**已渲染的 DOM 不会重算语言行为**。这是最常被忽略的陷阱。
- 已存在的
<p>こんにちは</p>仍按旧lang解析，屏幕阅读器不会重新加载日语语音引擎 - CSS
:lang(ja)规则不会对已有元素重新匹配，除非强制触发重绘（不现实） - 正确做法是：给目标元素显式加
lang="ja"，例如<blockquote lang="ja">…</blockquote>
真正难的不是设 lang，而是在组件化、国际化框架（如 i18n、react-intl）中保持 lang 属性与实际文本语言严格同步——尤其当文案来自 CMS、用户输入或翻译 API 时，很容易漏掉局部 lang 注入。这个细节没有报错提示，但一上线就影响无障碍合规和多语言 SEO。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
