unicode-range本身不引发下载冲突，但同font-family下范围重叠或遗漏关键码位（如空格、标点）会导致浏览器匹配混乱、重复加载或回退失效；旧浏览器需@supports降级，Safari须JS动态注入规避预加载。
unicode-range 本身不会导致“下载冲突”，但多个 @font-face 声明共用同一 font-family 名、又未严格隔离字符范围时，浏览器会因匹配逻辑混乱而重复加载、错配字体，甚至回退失效——这不是并发冲突，是规则设计错误。
为什么浏览器会重复下载同一字体文件
当两个 @font-face 声明使用相同 font-family 但 unicode-range 有重叠（比如都写了 U+4E00-9FFF），Chrome 可能只加载第一个，Firefox 却可能触发两次 fetch；更常见的是：某个声明漏了 U+0020（空格），导致中英文混排时部分字符 fallback 到系统字体，浏览器误判“当前字体不支持”，转而尝试下一个声明——看起来像“冲突”，实则是匹配断裂。
- 验证方法：DevTools → Network → 过滤
.woff2，看是否出现重复请求，再比对请求 URL 是否完全一致 - 真正触发重复下载的，往往是
src中写了多个 format（如url(a.woff2), url(a.woff)），Safari 会为每个 format 单独发起预加载 - 如果两个声明的
font-weight或font-style不一致（比如一个是normal，一个是400），浏览器可能拒绝合并，当作两个独立字体处理
如何写不重叠的 unicode-range 范围
中文场景下最容易踩坑的是“以为覆盖了汉字就完了”，结果标点、全角 ASCII、组合符号全被漏掉，迫使浏览器 fallback 并尝试其他声明。
- 必须包含
U+0020（空格）和U+0009（tab）：否则中英文混排时断行异常，且浏览器认为该字体“不适用”，跳过匹配 - 中文标点不能只写
U+3000-303F：还得加U+FF00-FFEF（全角 ASCII）、U+2000-206F（窄/宽空格、断行控制符） - 避免用简写形式：写
U+4E00-9FFF没问题，但U+4E00-U+9FFF（带U+前缀）在 iOS 9.3 前 Safari 会被静默丢弃 - 多段范围之间用英文逗号分隔，末尾不能有逗号，连字符
-前后不能有空格
旧浏览器里 unicode-range 被忽略怎么办
IE11、Android 4.4 WebView、iOS 9.2 及更早 Safari 根本不解析 unicode-range，整条 @font-face 规则被当作无范围限制的全量字体处理——此时若你只提供了子集文件，就会大面积显示方框。
- 用
@supports not (unicode-range: U+0)包裹降级规则，在不支持的环境里加载完整字体 - 每个子集字体必须声明独立的
font-family名（如'MyFont-ZH'、'MyFont-EN'），主 CSS 中用font-family: 'MyFont-ZH', 'MyFont-EN', sans-serif显式兜底 - 对 Android 旧设备，拆分后的字体文件
post表（PostScript name）必须重置，否则它们会被识别为同一字体的不同粗细，导致加载失败
Safari 预加载整个字体文件怎么绕过
iOS Safari 把 unicode-range 当作可用性提示，只要 DOM 里出现任一命中字符，就预取整个 WOFF2 文件——哪怕你只用了两个字。这不是 bug，是它的设计逻辑。
立即学习“前端免费学习笔记（深入）”；
- 唯一可靠方式：用 JavaScript 动态注入
@font-face，仅在检测到真实需要该字符范围时才加载对应子集 - 避免在
src中混写多个 format，Safari 容易因 fallback 机制放弃unicode-range优化 - 若必须兼容旧版 Safari，把中文子集单独抽成一个
font-family，用lang="zh"+ JS 检测语言属性来触发加载，比纯 CSS 更可控
unicode-range 只是开关，不是切刀。漏掉一个标点或空格，就足以让整套机制在真实页面中崩塌。 
