最可靠方式是用lang属性配合CSS属性选择器精准匹配语言并设置对应字体栈，需在文本元素上声明lang，每个语言单独定义@font-face，末尾保留系统默认字体族。
怎么用 lang 属性触发不同字体加载
浏览器原生支持通过 lang 属性匹配 CSS 选择器，这是最轻量、最可靠的方式。关键不是“切换字体”，而是让每种语言的文本节点自动带上对应字体栈。
-
lang必须写在包裹文本的元素上（比如<p lang="ja">），不能只写在<html>根标签——否则子元素不会继承字体行为（除非显式声明font-family: inherit） - CSS 中用属性选择器精准匹配：
[lang="zh"]、[lang="ja"]、[lang="ko"]，避免用模糊的[lang^="zh"]，它会误中zh-Hant和zh-Hans的共用规则 - 字体栈末尾务必保留系统默认字体族，比如
font-family: "PingFang SC", "Hiragino Sans GB", sans-serif，否则某语言字体加载失败时会直接回退到英文 fallback
@font-face 加载字体时怎么按语言分组
别把所有语言字体塞进一个 @font-face 块。不同语言字重、字形覆盖范围差异大，强行合并会导致体积膨胀或渲染异常。
- 每个语言单独定义
@font-face，用font-family名区分，比如font-family: "NotoSansCJK-zh"和font-family: "NotoSansCJK-ja" -
unicode-range是辅助手段，不是替代方案——它只控制字符映射，不解决字体文件加载时机；必须配合lang选择器才能真正隔离加载 - WebFont 加载延迟明显时，先用
font-display: swap防止文字闪白，但注意：日文/韩文字体文件普遍 >2MB，建议搭配preload提前拉取关键语言字体
为什么 font-language-override 不适合多语言排版
这个 CSS 属性本意是微调 OpenType 特性（比如让拉丁字母启用特定连字），不是为多语言网站设计的排版开关。
- 它不改变字体文件加载行为，只影响已加载字体的渲染逻辑
- 浏览器支持极差：Chrome 仅部分支持，Firefox 完全不支持，Safari 未实现
- 无法处理中日韩混排场景——比如一段里既有中文又有日文汉字，
font-language-override无法按字符粒度切分语言策略
服务端注入 lang 属性时容易漏掉哪些地方
静态 HTML 模板里手动写 lang 很容易遗漏动态内容，尤其是富文本、用户评论、第三方组件返回的 HTML。
立即学习“前端免费学习笔记（深入）”；
- Markdown 渲染器输出的
<p>默认没lang，需在解析阶段根据上下文补上，比如用 remark 插件识别代码块里的语言标识符 - React/Vue 组件内动态插入的文本，如果用
v-html或dangerouslySetInnerHTML，原始 HTML 若不含lang，就彻底丢失语言语义 - SEO 友好要求：搜索引擎依赖
lang判断页面主语言，首页<html lang="en">但正文大量中文却没标注[lang="zh"]，可能被误判为语言混乱页面
真正麻烦的是混排文本——同一段落里中英日夹杂，此时 lang 只能标在整段上，而字体切换必须靠 Unicode 范围或 JS 动态包裹。这种场景没有银弹，得接受部分字符用 fallback 字体渲染。
