font-feature-settings 失效主因是写法错误、字体缺失或加载时机不当，而非浏览器兼容性问题；chrome 中值被划掉说明解析失败，需检查引号、逗号及0/1格式；safari 静默忽略无对应特性的字体；tnum等特性需字体真实支持；首屏无连字多因font-display: swap导致延迟渲染。
font-feature-settings 本身在现代浏览器中兼容性很好，问题几乎从不来自“浏览器不支持”，而是写法错误、字体缺失或加载时机不对。
Chrome DevTools 里值被划掉？先查这三处硬伤
只要 font-feature-settings 的值在 Elements → Computed 面板里显示为灰色并带删除线，就说明浏览器压根没解析成功——后续所有效果都无从谈起。
-
liga1（缺引号）→ 必须写成"liga"1 -
"liga"on 或"liga"true → 规范只接受1或0，布尔值或别名不被识别 -
"liga"1"dlig"1（漏逗号）→ 正确是"liga"1,"dlig"1
Safari 上连字不出现？大概率不是它不支持
Safari 15.4+ 支持 "liga" 1，但 macOS Safari 对 OpenType 特性的激活更保守：它不会忽略语法正确的声明，但会静默跳过字体里没打包的特性，也不会报错或警告。
- Google Fonts 默认加载的
Inter、Roboto不含dlig表，写了"dlig"1 也白搭 - 用 FontDrop 上传你实际使用的 WOFF2 文件，搜索
liga或dlig，确认特性真实存在 - Safari 的 Fonts 面板不显示 OpenType 特性勾选状态，得靠测试文本（如
fi fl ct st 1/2）+ Computed 面板双重验证
写了 "tnum" 1 却数字还是不等宽？字体没打包才是真瓶颈
font-variant-numeric: tabular-nums 在 Safari ≤15.3 和 Firefox ≤91 中直接被忽略，但 font-feature-settings: "tnum" 能穿透到更底层，兼容性反而更好——前提是字体真有 tnum 表。
- iOS 系统默认用的
SF UI Text不支持tnum，只有SF Pro Display才有 - Google Fonts 的
roboto-v20-latin子集默认不含tnum，需手动加&text=0123456789参数触发完整版加载 - 验证方式简单：给元素加
font-feature-settings: "tnum"，再看0123456789是否视觉等宽；不等宽就换字体，别调 CSS
首屏没连字，过一秒才出现？font-display: swap 在背锅
你写的没错、字体也带表、浏览器也支持，但用户第一眼看到的是系统字体（如 San Francisco），Web 字体加载完才重绘——你以为“失效”，其实是延迟。
- 把
@font-face中的font-display临时改成block测试：若连字立刻出现，就是加载策略问题 - 不要用
optional，它可能导致字体不加载，连字永远不出现 - 对关键文本（如数字动画），可加
font-feature-settings: "tnum"到系统字体栈 fallback 中，缓解震颤
真正容易被忽略的，是“启用特性”和“字体加载完成”之间那层看不见的时序差——它让所有调试都变成幻觉，直到你打开 Network 面板盯着字体请求跑完为止。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
