必须在标签上设置lang属性且值严格匹配页面主语言，否则屏幕阅读器、翻译工具和seo将全部误判；仅修改无效，因浏览器和读屏软件只在初始解析时读取的lang值。
必须写在 标签上，且值要严格匹配当前页面主语言；否则屏幕阅读器、翻译工具、SEO 全部误判——这不是“锦上添花”，而是“底线要求”。
为什么只改
浏览器和读屏软件（NVDA、VoiceOver）只在解析初始 HTML 时读取 的 lang 值，作为整页语言依据。后续任何修改都晚了。
-
→ 不被识别为文档语言，仅影响极少数子元素的局部断词，实际无用 <div lang="en"> → 语义缺失，读屏不把它当语言单元，硬读效果差<li> <code><meta http-equiv="Content-Language" content="zh-CN">→ HTML5 已弃用，Chrome/Firefox/Safari 全部忽略-
document.documentElement.lang = "en-US"（JS 执行）→ 已加载页面中，语音引擎不重载，:lang()CSS 不重计算，翻译按钮不刷新 - Chrome 自动翻译按钮不出现，或点了直接翻成日语——它信了你写的
lang="ja"，哪怕页面全是汉字 - iOS VoiceOver 把“行”(xíng) 读成“行”(háng)，因为没
lang="zh-CN"就默认按英文规则切音节 - Google 可能把全中文页当“未标注语言”降权，尤其多语言站点中缺失
hreflang联动时 - CSS 伪类如
:lang(zh)无法匹配，导致针对中文的排版规则（如避头尾、标点挤压）失效 - 单个外文词：
<code lang="en">useState→ 读作 /ˈjuːzˌsteɪt/，不是“优斯态特” - 整段英文：
<p lang="en">This is a code example.</p> - 代码块注释：
<pre class="brush:php;toolbar:false;" lang="en"># Initialize counter</pre>（注意不是lang="bash"） - 引文类语义标签更可靠：
<blockquote lang="fr">…</blockquote>、<q lang="ja">…</q> - 必须同步更新所有已有
lang属性的元素，比如<p lang="en"></p>、<pre class="brush:php;toolbar:false;" lang="bash"></pre>，否则它们仍按旧语言处理 - 服务端渲染（Next.js/Nuxt）务必在 HTML 初始响应中就输出正确
lang，不要等 JS 执行后再补——首屏对 SEO 和无障碍最关键 - 纯前端 SPA 若支持多语言，不能靠 JS patch，应产出不同
lang的 HTML 入口文件（SSG）或使用 SSR
lang 值选错会直接触发哪些故障
表面看页面照常显示，但背后链路已悄悄断裂：辅助技术误读、机器翻译乱套、搜索结果降权、甚至某些 CDN 或缓存策略失效。
多语言混排时，lang 怎么嵌套才真正起作用
主语言靠 确立，但嵌入的英文术语、日文引用、代码注释等，必须显式标注子元素的 lang，否则读屏仍用中文规则硬读。
动态页面更新 lang 的真实约束
SPA 切换语言后，只改 document.documentElement.lang 还不够——已渲染的 DOM 不会重新触发翻译逻辑，屏幕阅读器也不会自动切换语音引擎。
最容易被忽略的一点是：lang 是每个元素自身的语言声明，不是继承来的“配置项”。浏览器、读屏、拼写检查器，全按每个节点明写的 lang 值工作——哪怕只漏了一个 <code lang="en">，那个单词就会被中文语音引擎生硬朗读。
