应根据内容面向的用户地区选择lang值，而非服务器位置；如面向英国用户则用lang="en-gb"，面向美国用户则用lang="en-us"，错误会导致拼写检查、语音朗读、字体回退及css样式失效。
lang="en-US"和lang="en-GB"到底该用哪个
不是看服务器在哪儿，而是看内容面向谁。比如一个面向英国用户的帮助文档，即使部署在美国云上，html标签也得写lang="en-GB"；同理，美国用户看到的定价页必须是lang="en-US"。写错会导致拼写检查用美式规则校验英式单词（比如把“colour”标红）、语音引擎选错发音库（“schedule”读成/ˈskɛdʒuːl/而非/ˈʃɛdjuːl/）、甚至影响字体回退——某些中文字体里嵌的英文字形会按地区偏好微调。
en-AU、en-CA这些变体要不要加
要，但得看实际需求。如果你的页面里有大量本地化表达（比如用“lift”代替“elevator”，或价格单位写“AUD $”），就必须显式标注对应地区码。否则浏览器可能把en当成通用英文处理，导致：
- Chrome 翻译按钮默认推荐“简体中文”，而不是按用户地理位置匹配的方言模型
- 屏幕阅读器对“tomato”这类词的重音位置判断出错（美式 /təˈmeɪtoʊ/ vs 英式 /təˈmɑːtəʊ/）
-
:lang(en-GB) { quotes: "«" "»"; }这类样式完全不生效
常见合法值：en-US、en-GB、en-AU、en-CA、en-NZ。别用en_uk或english-uk——下划线和非BCP 47名称全被静默忽略。
只写lang="en"会怎样
等于没写地区信息。虽然浏览器能识别为英文，但所有地域敏感行为都会退化到最宽泛的en基线：
- SEO：Google Search Console 可能报“语言未明确指定”，影响多区域索引
- 拼写检查：不会自动切换牛津词典或韦氏词典词库
- 语音朗读：iOS VoiceOver 可能随机选一个英语发音引擎，用户听到的口音不稳定
- CSS
:lang(en)能匹配所有en-*，但反过来:lang(en-US)不匹配lang="en"，样式策略容易漏掉
混排时怎么处理美式术语+英式拼写
不能靠一个根lang撑全场。比如一段技术文档里既有美式命令curl -X POST，又引用了英式原文"The programme is running"，就得拆开标：
<p lang="en-US">Run <code lang="en-US">curl -X POST</code> to trigger the endpoint.</p> <blockquote lang="en-GB"><p>The programme is running.</p></blockquote>
注意：code元素本身不带语义，必须显式加lang；blockquote天然适合包裹外文引文，比div更利于辅助技术理解上下文。别图省事给整个section加lang="en-GB"再在里面塞美式术语——那会让屏幕阅读器把“color”也按英式读成/ˈkʌlə/。
最容易被忽略的是：地区码一旦写错，比如en-us（小写us）或en_UK（下划线），浏览器不会报错，但所有依赖它的功能都失效。验证时直接看document.documentElement.lang输出是否严格等于en-US这种大小写+短横线组合。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
