lang属性必须写在<html>标签上，是浏览器、搜索引擎和辅助技术识别页面语言的第一依据；局部切换需用内联lang显式声明，且值须符合BCP 47标准，如zh-CN、en-US。

lang 属性写在 <html> 标签上，不是“可有可无的装饰”，而是浏览器、搜索引擎和辅助技术识别页面语言的**第一依据**。没它，中文页面可能被当成英文朗读，SEO 降权，字体回退错乱，拼写检查失效——这些都不是理论风险，是真实发生的故障。

为什么必须设在 <html> 标签上？

根元素的 lang 是整个文档的默认语言源头，具有继承性：所有子元素在未显式声明 lang 时，都按它来解析。

• 屏幕阅读器靠它决定发音规则，比如 “lead” 在英语里读 /liːd/（动词）还是 /led/（名词），中文混排英文术语时若根 lang 错了，整段语音输出会失真
• Chrome 和 Safari 的内置翻译功能，优先读取 <html lang> 而非 HTTP Content-Language 头或页面内容统计结果
• CSS 中的 :lang(en) 伪类、quotes 属性、某些字体回退链（如 font-family: "PingFang SC", "Helvetica Neue", sans-serif）都依赖根语言判断渲染逻辑

lang 值怎么写才合法？

必须用 BCP 47 标准格式，不是随便填个字符串就行。常见错误包括：zh_CN、chinese、en-us（小写连字符不推荐）、zh-Hans-CN（过度冗余）。

Article To Html

文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。

下载

• 简体中文用 zh-CN 或更推荐的 zh-Hans（不绑定国家，适配港澳台简体场景）
• 美式英语用 en-US，英式用 en-GB；只写 en 也合法，但丢失地域习惯（如日期格式、标点间距）
• IANA Language Subtag Registry 是唯一权威来源，别信网上搜到的“常用代码表”——比如 pt-BR 正确，bra 或 portuguese-br 全错

局部语言切换为什么不能只改 document.documentElement.lang？

JS 动态修改 document.documentElement.lang = 'ja' 只影响根节点及其后续新插入的子元素，**已渲染的 DOM 不会重算语言行为**。这是最常被忽略的陷阱。

立即学习“前端免费学习笔记（深入）”；

• 已存在的 <p>こんにちは</p> 仍按旧 lang 解析，屏幕阅读器不会重新加载日语语音引擎
• CSS :lang(ja) 规则不会对已有元素重新匹配，除非强制触发重绘（不现实）
• 正确做法是：给目标元素显式加 lang="ja"，例如 <blockquote lang="ja">…</blockquote>

真正难的不是设 lang，而是在组件化、国际化框架（如 i18n、react-intl）中保持 lang 属性与实际文本语言严格同步——尤其当文案来自 CMS、用户输入或翻译 API 时，很容易漏掉局部 lang 注入。这个细节没有报错提示，但一上线就影响无障碍合规和多语言 SEO。