必须使用 en-US 或 en-GB：因 en 违反 BCP 47，缺乏地域信息，导致语音合成、CSS :lang 匹配、CDN 分发等多链路失效；选型取决于目标用户拼写与格式习惯，不可混用。
必须用 en-US 或 en-GB，不能写 en、english 或 en_US——否则屏幕阅读器可能跳过英文 TTS 引擎，Chrome 翻译按钮不出现，Google Search Console 报“未指定语言”。
为什么 en 不够用
单写 en 违反 BCP 47 规范，且缺乏地域信息，导致多个链路失效：
- 语音合成引擎无法确定拼写规则和音标（比如
colorvscolour），iOS VoiceOver 可能 fallback 到美式发音库读英式文本 - CSS 的
:lang(en)在旧版 Safari 中匹配不稳定，影响字体回退或标点挤压规则 - 部分 CDN 和缓存策略依赖完整语言标签做内容分发，
en被视为“未声明区域”，可能降级处理
en-US 和 en-GB 怎么选
选哪个取决于你实际面向的用户群体和内容规范，不是“哪个更标准”：
- 面向美国用户、使用美式拼写（
center、organize）、日期格式为MM/DD/YYYY→ 用en-US - 面向英国/澳大利亚/新西兰等地区、用英式拼写（
centre、organise）、日期为DD/MM/YYYY→ 用en-GB - 不要混用：页面里写
en-US却大量用colour，会触发浏览器拼写检查误报，也干扰翻译工具词典匹配
多语言英文内容怎么标注
主语言是英文，但嵌入了其他语言片段（如法语引用、日文术语、代码注释），必须显式覆盖子元素的 lang：
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
立即学习“前端免费学习笔记（深入）”；
- 整段非英语内容：
<p lang="fr">Merci beaucoup.</p>，不能只靠 CSS 或 class 模拟 - 技术文档中的代码块注释：
<pre lang="en"># Initialize counter</pre>—— 注意这里不是lang="python"，语言标签描述的是注释文本语言，不是代码语言 - 避免
<div lang="ja">包裹大段 HTML —— 语义不清，且可能干扰父级:lang(en)样式匹配 -
<blockquote lang="de">比<span lang="de">更合适，因为引文自带语义边界，读屏软件识别更准确
动态页面中更新英文语言标识的风险点
React/Vue/Next.js 等框架容易在这里翻车：JS 设置 document.documentElement.lang = "en-GB" 是无效补救——首屏 HTML 已被解析并送入读屏缓冲区。
- SSR/SSG 必须在服务端模板或构建时注入真实值，例如 Next.js 的
app/layout.tsx中用<html lang={locale}>，locale来自路由参数或配置 - 纯 CSR 应用若支持多语言，需生成多个静态 HTML 入口（如
/en-us/index.html、/en-gb/index.html），而非靠 JS 切换 - 切语言时只改文案不改
<html lang>，会导致 VoiceOver 继续用en-US引擎读en-GB文本，把schedule读成 /ˈskɛdʒuːl/ 而非 /ˈʃɛdjuːl/
最常被忽略的一点：hreflang 和 lang 完全无关。页面设了 <html lang="en-GB">，但 <link rel="alternate" hreflang="en-US"> 指向另一个 URL，搜索引擎会照常索引，但浏览器不会因此改变当前页的语言行为——两者必须各自独立、语义一致地维护。
