unicode-range在IE11、Android 4.4 WebView及iOS 9.3前Safari中不支持或解析异常，导致字体回退失效；需用JavaScript检测lang属性加载子集、@supports降级、独立font-family兜底并清洗字体name表。
unicode-range 在旧版浏览器（如 IE11、Android 4.4 WebView、部分旧版 Safari）中支持不全或完全忽略，直接导致字体回退失效、中文乱码、或全部字符强制走默认字体——这不是你写错了，是浏览器压根没解析这个属性。
哪些浏览器会跳过 unicode-range
IE11 及更早版本完全不支持 unicode-range；Android 4.4 系统 WebView（基于 Blink 30）仅部分识别，且对多段范围（如 U+4E00-U+9FFF, U+3000-U+303F）常只取第一段；iOS 9.3 之前的 Safari 对 U+ 后缀写法兼容性差，写成 U+4E00-9FFF（缺前导零）可能被静默丢弃。
验证方式很简单：在目标设备打开 DevTools → 查看 @font-face 规则 → 如果 unicode-range 行显示为灰色或带删除线，基本就是被忽略。
拆分字体文件时必须避开的三个坑
不是简单把一个 WOFF2 拆成几份就完事，拆得不合理反而让加载更慢、渲染更卡：
- 别按「字数均分」：汉字常用字集中在
U+4E00-U+9FFF，但高频字实际只占前 3000 个码位；U+3400-U+4DBF（扩展 A）和U+9FA6-U+9FFF（生僻字）极少出现，却占体积大——这些应单独切出并设font-display: optional - 别漏掉标点和符号：中文排版离不开
U+3000-U+303F（中文标点）、U+2000-U+206F（空格与断行控制符），漏掉会导致句号、顿号、全角空格用系统字体渲染，字号/基线错位 - 别混用格式：同一字体族下，不同
@font-face声明必须保持font-weight和font-style一致，否则浏览器可能拒绝合并匹配，转而触发多次下载
@font-face 拆分后如何确保 fallback 正常工作
核心原则：让浏览器「有得选，且选得对」。即使 unicode-range 失效，也要靠 font-family 列表顺序兜底：
- 每个拆分后的字体都声明独立的
font-family名（如'MyFont-CN-Core'、'MyFont-CN-Ext'），避免重名覆盖 - 主 CSS 中统一用
font-family: 'MyFont-CN-Core', 'MyFont-CN-Ext', system-ui, sans-serif;，不依赖unicode-range触发，而是靠浏览器逐个尝试加载并匹配字符 - 对 IE11 等老内核，加一层
@supports not (unicode-range: U+0) {}条件包裹，里面降级为单个全量字体 +font-display: swap，防止白屏
最易被忽略的一点：拆分后每个字体文件的 post 表（PostScript 名称表）若未重置，某些旧 Android 设备会把它们识别为「同一字体的不同粗细」，导致只加载第一个、其余静默丢弃——生成时务必用 fonttools 或 glyphhanger 清洗 name ID 1 和 4。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
