必须使用标准语言标签如en-US而非english，否则导致屏幕阅读器误读、SEO失效、CSS不匹配；嵌入外语需显式标注lang属性；SPA切换语言须手动更新所有lang值。
为什么 `` 不能写成 ``
因为 english 不是 BCP 47 语言标签，浏览器会静默降级为 und（未知语言），导致屏幕阅读器按系统默认语种朗读、SEO 丢失语言信号、:lang(en) CSS 规则完全不匹配。
必须用标准 ISO 639-1 语言码 + 可选区域子标签：en（通用英语）、en-US（美式英语）、en-GB（英式英语）。其中 en-US 是最稳妥的选择——它明确区分拼写、标点、语音引擎，且被所有主流辅助技术完整支持。
-
en：合法但粒度太粗，部分旧版 Safari 对:lang(en)匹配不稳定 -
en-US：推荐首选，Chrome/NVDA/VoiceOver 全链路识别最准 -
en-gb或EN-US：大小写混用或小写错误，iOS VoiceOver 某些版本会拒绝加载英语 TTS 引擎 -
en_US：下划线非法，等同于没写，Google Search Console 可能报“未指定语言”
英文页面里嵌法语引文，只靠 `` 够吗
不够。浏览器不会自动推断「这段斜体文字是法语」，它只认你明写的 lang 属性。不加，屏幕阅读器就用英语规则硬读法语单词，比如把 Je suis français 读成 /ʒə sɥi frɑ̃sɛ/ → /dʒi swi frænˈsɪs/，语义全失。
必须显式标注语义合理的容器元素：
立即学习“前端免费学习笔记（深入）”；
- 引文用
<blockquote lang="fr">，比<p lang="fr">更准确，读屏软件会触发法语停顿和重音规则 - 术语或短句可用
<span lang="de">Zeitgeist</span>，但避免滥用——每个lang都增加可访问性树构建开销 -
<pre lang="bash">这类写法虽非标准语言码，但被语法高亮工具和 Chrome DevTools 识别为代码上下文，可保留；但注释里的英文应写<pre lang="en">而非留空，防止被误译
React/Vue SPA 切换到英文页，只改文案不改 lang 会怎样
已渲染的 DOM 不会重触发翻译、语音引擎或字体 fallback，后果是：VoiceOver 继续用中文发音引擎读英文单词，标点间距仍是中文样式，Chrome 翻译按钮可能消失，甚至把英文页当成「需要翻译成英文」的异常页面处理。
关键动作不是改状态，而是同步更新语言声明：
- 第一件事：执行
document.documentElement.lang = "en-US" - 第二件事：遍历所有已有
lang属性的元素（如<pre lang="en">、<blockquote lang="fr">），批量更新其lang值 - 纯客户端渲染（CSR）项目，若做不到首屏 HTML 就输出正确
lang，建议加location.reload()强制刷新——比 JS patch 更可靠 - Next.js 用户应在
app/layout.tsx中绑定<html lang={locale}>，确保 SSR 阶段就写入
lang="en" 和 hreflang="en" 能互相替代吗
不能。它们作用域完全不同：lang 是内容层标记，告诉浏览器「这段文字是什么语言」；hreflang 是链接关系声明，只对搜索引擎生效，用于多语言 URL 分流。
典型错误是：在英文页面里写了 <link rel="alternate" hreflang="en" href="/en/">，却忘了自己页面的 <html lang="en"> 还是 zh-CN。结果搜索引擎以为这是中文站的一个英文镜像，而用户点进来后，页面仍按中文渲染——字体错、标点挤、VoiceOver 乱读。
-
hreflang必须成对出现：英文页要声明hreflang="en"和hreflang="zh"，中文页也要反向声明 -
hreflang="x-default"推荐指向英文页，但前提是该页的<html lang="en">真实有效 - 两者值必须严格一致：hreflang="en-US" 的目标页，
<html lang="en-US">也得是同一值，否则 Google 可能忽略整个 hreflang 声明
lang 属性不会自动继承或重算——你得亲手改每一个带 lang 的节点，而不是指望父级一变，子级全跟着变。 
