lang属性写错或漏设会导致浏览器跳过中文字体链而强制使用西文字体，因浏览器仅依据合法bcp 47格式（如zh-cn）触发语言感知字体链，非法值（如zh_cn）或缺失声明会使中文被当latin-1解析，引发标点异常、间距爆炸及方块显示。
lang 属性写错或漏设，中文字体就会被当英文渲染——这不是字体没加载，是浏览器压根没打算用中文字体。
为什么 lang 错了字体就糊成一片
浏览器不靠内容猜语言，只按 lang 值触发内置的「语言感知字体链」。比如 Safari 看到 lang="zh-CN" 才会优先尝试 "PingFang SC"；若值是 zh_cn、zh 或根本没写，整段中文就被扔进西文 fallback 链，最终落到 Courier New 或 Times 上——结果就是标点撑开、引号变英文、混排时中文糊成一片，甚至直接显示方块。
常见错误现象包括：
- Mac 上中文显示为方块（
lang错成zh_cn，Safari 直接跳过PingFang SC） - 同一行中英混排，英文正常、中文间距爆炸（
lang缺失 → 中文被当 Latin-1 字符流解析） -
«»变成" "，且左右空隙异常（Chrome 对lang="en"的中文段落禁用中文标点挤压规则）
lang 必须怎么写才有效
必须严格遵循 BCP 47 标准，小写 + 连字符，不能有空格或下划线：
- 简体中文首选
zh-CN：全链路兼容最稳，NVDA、VoiceOver、Chrome、Google SEO 全认 - 繁体中文用
zh-TW或zh-HK，别混用zh-Hant（旧版 Safari 匹配不准） - 日语必须写
ja-JP，ja在 iOS VoiceOver 和 Safari 中支持不稳定 - 绝对避免：
zh_CN、Chinese、zh（太宽泛）、zh-china（大小写混用非法）
后端返回的 lang 值（如 ZH-CN 或 zh_ch）需前端转为小写+连字符，否则被静默忽略。
局部多语言内容必须显式声明 lang
只在 设一次，不代表全页中文都走中文字体链。夹在中文里的英文段落、代码注释、法语引文，若没显式加 lang，就会继承 zh-CN，被塞进“微软雅黑”里渲染——字母挤压、标点错位。
正确做法是语义合理 + 显式标注：
<p lang="en">Save draft</p>-
<pre class="brush:php;toolbar:false;" lang="bash">curl -X POST</pre>（不是lang="en"） <blockquote lang="fr">Je suis français.</blockquote>- 不要给每个单词都套
<span lang="en"></span>——DOM 膨胀，可访问性树构建变慢
:lang() 选择器和字体链怎么配才不翻车
:lang(zh) 理论上能匹配 zh-CN、zh-TW，但实际取决于底层解析器是否把 zh-CN 识别为 zh 的子类。Chrome 和 Safari 行为不一致，尤其 SSR 后 JS 动态改 lang 时，:lang(zh) 可能只命中根节点。
更稳妥的是属性选择器兜底：
html[lang^="zh"] { font-family: "PingFang SC", "Microsoft YaHei", sans-serif; }- 注意：
lang^="zh"也会匹配lang="zhx"这种非法值，慎用
字体链顺序决定一切：
- 把该语言专用字体放最前：
"PingFang SC"（简体）、"Hiragino Kaku Gothic Pro"（日文） - 避免跨语言混搭：别在
:lang(zh)里塞"Meiryo"，它对中文支持弱，易出字形错位 - 末尾必须是
sans-serif或serif，不能是system-ui——它会绕过所有语言专用字体，直奔系统默认拉丁字体
真正难的不是设对一个 lang="zh-CN"，而是让每个动态插入、跨框架、第三方脚本生成的文本节点，都带着准确的语言上下文被解析——这一步漏了，字体回退就从源头失效。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
