font-variant-numeric: tabular-nums 在移动端常失效，主因是系统字体（如pingfang sc、roboto子集）缺失tnum opentype特性；需显式声明支持该特性的字体栈（如sf mono、fira code）并分离数字与单位结构。
font-variant-numeric: tabular-nums 在移动端几乎必然失效，除非你主动控制字体栈——它不是 CSS 写错了，而是系统默认字体根本不带 tnum OpenType 特性。
为什么写了 font-variant-numeric: tabular-nums 却没变化
移动端（iOS Safari、Android Chrome）里该属性“静默失效”是常态，原因非常具体：
- iOS 的
PingFang SC、SF UI Text（非 Pro 版）不包含tnum变体；Android 的Roboto默认 Web 字体子集也不含该特性 - 即使
getComputedStyle(el).fontVariantNumeric返回"tabular-nums"，也只是说明 CSS 被解析了，不代表渲染生效 - 真正验证方式：用 DevTools 量
"0"和"1"的像素宽度是否相等；不等宽 = 字体不支持，不是浏览器兼容问题
怎么选一个真正支持 tabular-nums 的字体栈
别依赖系统字体，显式声明已知打包了 tnum 的开源字体，并兜底到 monospace：
- 推荐组合：
font-family: "SF Mono", "Fira Code", "IBM Plex Mono", monospace; -
SF Mono是 macOS/iOS 上最稳定的选择，体积小、支持完整 OpenType 数字特性 - 避免只写
monospace：它强制所有字符等宽，但字母/汉字会被拉平，可读性下降，且不保证启用tnum字形 - Google Fonts 加载 Roboto 时，必须加
&text=0123456789参数才能触发含tnum的子集，否则还是基础版
表格或数字+单位混合时对齐仍然错乱
font-variant-numeric 只作用于纯数字字符（U+0030–U+0039），对 "kg"、"%"、"℃" 等单位完全无效：
- 结构分离是唯一可靠解法：把数字包进
<span class="num">123</span>，单位单独放<span class="unit">kg</span> - 给
.num加font-variant-numeric: tabular-nums+ 显式等宽字体栈；给.unit设固定width或统一padding-left - 不要指望
@supports (font-variant-numeric: tabular-nums)判断：旧版 Safari 检测常返回true但实际不渲染，Firefox ≤91 常返回false即使写了属性
需要 JS 实测支持状态时怎么做
当必须区分真实渲染能力（比如做降级 fallback），不能靠 @supports，得实测视觉效果：
- 创建临时
span，设style.fontVariantNumeric = "tabular-nums"，内容为"0123456789" - 用
getBoundingClientRect().width获取总宽度，再对比未设该属性时的宽度波动（需同字体、同字号） - 注意：这个方法在 iOS WKWebView 中可能受字体加载时机影响，建议延迟到
font-display: optional加载完成后再测
最常被忽略的一点：移动端字体文件本身是否含 tnum 特性，比浏览器版本重要得多。Safari 15.4+ 支持该属性，但若字体没打包，照样白搭。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
