lang属性必须设在标签且严格符合bcp 47标准(如zh-cn),小写+连字符,其他位置或非标写法(如zh_cn、chinese、zh)均被浏览器、屏幕阅读器和搜索引擎忽略,导致翻译、朗读、seo等功能失效。

lang属性值必须查 IETF BCP 47,不是ISO 639或W3C随便列的列表
浏览器、屏幕阅读器、搜索引擎只认 IETF 发布的 BCP 47 标准,不是 ISO 639-1(如 zh、en)的两字母码,也不是 W3C 文档里举例用的宽松写法。查错地方,就等于白设。
常见错误是去搜“HTML lang 中文代码”,结果抄到 zh、ch、Chinese 这类非标准值——它们可能通过 W3C 验证,但 NVDA、VoiceOver、Chrome 翻译按钮全不认。
-
zh-CN是简体中文事实标准,所有主流辅助技术链路验证过 -
zh-TW和zh-HK是繁体唯一有效值;zh-Hant在 Safari 的:lang()CSS 选择器中匹配不准,慎用 -
zh-Hans虽属 BCP 47,但部分旧版 JAWS 和 Android TalkBack 支持不稳定,不建议生产环境首选 - 大小写敏感:必须全小写+连字符,
ZH-CN、zh_cn、zh CN全被静默忽略
直接查 BCP 47 官方注册库:iana.org/langtags
最权威、实时更新的来源是 IANA 语言子标签注册表:https://www.iana.org/assignments/language-subtag-registry。它不是文档,而是机器可读的纯文本注册表,每行一个合法子标签。
搜索技巧:
- 用 Ctrl+F 搜
zh,会看到完整条目:Type: language<br>Subtag: zh<br>Description: Chinese<br>Added: 2005-10-16
—— 这只是基础语言标签,**不能单独用** - 继续搜
zh-CN,找到:Type: region<br>Subtag: CN<br>Description: China<br>Added: 2005-10-16
—— 说明zh-CN是合法组合 - 搜
zh-Hans,能看到它是Type: script,合法,但注意其Preferred-Value字段是否指向更稳的zh-CN
别依赖第三方整理页(比如某些博客列的“常用 lang 值表”),它们常混入已弃用或未注册值。
动态页面中怎么安全生成 lang 值
后端模板或 SSR 框架(如 Next.js、Nuxt)输出 时,locale 变量必须经过标准化校验,不能直接透传用户输入或配置项。
- 前端 JS 动态改
document.documentElement.lang仅对后续新激活的朗读会话生效,首屏已解析的 DOM 不会重读——所以校验必须在服务端做 - 推荐清洗逻辑:
locale.replace(/[^a-z0-9\-]/g, '').toLowerCase().replace(/^([a-z]{2})-([a-z]{2})$/, '$1-$2'),再白名单比对(只允许zh-CN、zh-TW、en-US等已知安全值) - PHP 模板中务必用
防 XSS,否则攻击者可注入zh-CN" onerror="alert(1)
为什么本地开发时 lang="zh" 看似正常,上线就出问题
本地用 Chrome 测试时,lang="zh" 可能触发翻译按钮或勉强朗读,是因为 Chrome 有宽松 fallback 逻辑;但 NVDA、iOS VoiceOver、Google Search Console 全部严格按 BCP 47 匹配,zh 不在它们的“可信区域子标签”白名单里,直接降级为系统默认语种(通常是英文)。
真实影响链:
- 语音朗读:把“上海”读成 /ʃæŋˈhaɪ/(英语音),而非 /ʂɑ̂ŋ.xàɪ/(中文)
- 标点渲染:中文顿号、书名号间距错乱,因字体 fallback 到英文 font-family
- SEO:Google Search Console 报 “Missing hreflang or language declaration”,影响收录权重
- 自动化测试:axe-core 直接标为
critical级别错误,CI 流水线失败
真正难的不是知道该写 zh-CN,而是确保每个 SSR 输出、每个微前端子应用、每个 CMS 导出的 HTML 片段,都带着这个精确值落地——漏一处,无障碍链路就断一环。
前端入门到VUE实战笔记:立即使用
在学习笔记中,你将探索 前端 的入门与实战技巧!











