必须使用 en-US，因为它是唯一被浏览器、读屏软件和搜索引擎完整识别的合法语言标签；单独写 en 丢失地域信息，english 和 en_US 均不符合 BCP 47 标准。
必须写成 en-US，不能用 en、english 或 en_US —— 后三者要么语义不全，要么非法，浏览器和读屏软件会静默忽略。
为什么只能用 en-US 而不是 en
单独写 en 虽然语法合法，但丢失了关键的地域信息：标点间距、日期格式、拼写习惯（如 color vs colour）、语音合成引擎选型都依赖地区子标签。Chrome 翻译按钮、VoiceOver 的美式发音、Google Search Console 的语言识别，全都优先匹配 en-US 这一完整值。
常见错误现象包括：
-
<html lang="en">→ Safari 可能 fallback 到英式语音库，把 “schedule” 读成 /ˈʃedjuːl/ 而非 /ˈskɛdʒuːl/ -
<html lang="english">→ BCP 47 标准不认，等同于未声明，SEO 工具报 “language not specified” -
<html lang="en_US">→ 下划线非法，浏览器降级为und（未知语言）
en-US 必须写在 <html> 标签上
这是唯一被浏览器、NVDA、VoiceOver 和 Google 识别的位置。其他写法全部无效：
立即学习“前端免费学习笔记（深入）”；
-
<body lang="en-US">→ 不触发页面级翻译入口，屏幕阅读器仍按系统默认语种朗读标题 -
<meta http-equiv="Content-Language" content="en-US">→ HTML5 已废弃，现代浏览器完全忽略 -
document.documentElement.lang = "en-US"（JS 执行）→ DOM 解析完成后才运行，读屏软件已加载初始语音库，改了也白改
正确写法只有一种：<html lang="en-US">
混排英文内容时，局部 lang 怎么加才有效
主语言是 en-US，不代表所有英文元素都要额外标注；只有语义明确、需区别处理的外文内容才加子元素 lang：
- 引文、术语、代码注释等有明确语义的节点才加，例如：
<blockquote lang="fr">Je vous remercie.</blockquote> -
<code lang="en">useState</code>可让 IDE 在中文环境里对英文 API 名启用英文高亮逻辑 - 避免无意义包裹：
<div lang="en"><p>Hello world</p></div>→ 语义不清，干扰:lang(en-US)CSS 匹配 -
<pre lang="bash">是错的——bash不是语言标签，应写<pre lang="en">或直接留空
动态页面中切换到美式英语的真正难点
难的不是设一个值，而是确保所有环节同步：
- 服务端渲染（如 Next.js）必须在
app/layout.tsx中用<html lang={locale}>，且locale必须精确等于"en-US"，不能是"en"或变量未初始化 - 纯前端 SPA 若支持多语言，不能靠 JS patch
lang属性来“模拟”切换——用户刷新后仍回退到旧值，且第三方脚本插入的文本节点无法自动继承新语言上下文 -
hreflang和lang无自动关联，<link rel="alternate" hreflang="en-US" href="/en-us/">必须手动与<html lang="en-US">保持一致，否则 Google 可能索引错版本
最常被忽略的一点：切换语言后，<title> 里的文字必须是美式英语，且 <html lang="en-US"> 必须出现在首屏 HTML 字符串中——任何延迟注入或字符串拼接都可能让 VoiceOver 读出中英混杂的标题。
