font-variant-numeric: tabular-nums 仅在字体支持 tnum OpenType 特性时生效，否则被忽略；它只作用于数字字符，需配合等宽字体栈和结构分离（如数字与单位分标签）实现精准对齐。
font-variant-numeric: tabular-nums 为什么没生效
直接原因是字体不支持 tnum OpenType 特性，CSS 只是“开关”，不是“生成器”。即使写了 font-variant-numeric: tabular-nums，若当前 font-family 中的字体未内嵌等宽数字字形（比如多数中文字体如 Microsoft YaHei、SimSun 完全忽略该属性），浏览器就当它不存在。
验证方式很简单：getComputedStyle(el).fontVariantNumeric 返回 "tabular-nums" 仅说明 CSS 被解析了，不代表实际渲染生效；真正要看的是数字是否视觉等宽——拿 "1" 和 "8" 并排对比宽度最直观。
- Windows 上优先试
"Segoe UI"或"Consolas" - macOS 上
"SF Mono"、"Menlo"支持稳定 - 跨平台推荐开源字体：
"Fira Code"、"IBM Plex Mono"、"JetBrains Mono" - 避免只写
monospace：它强制所有字符等宽，但会牺牲字母/汉字的可读性，且不保证数字使用tnum变体
font-feature-settings: "tnum" 是更底层的写法吗
是，但它不是替代方案，而是等价的底层控制。font-variant-numeric: tabular-nums 实际就是 font-feature-settings: "tnum" 的语义化封装。两者在支持该特性的浏览器中效果一致，但 font-feature-settings 更“硬”，也更难维护。
关键区别在于：
立即学习“前端免费学习笔记（深入）”；
-
font-variant-numeric可叠加其他值，如tabular-nums oldstyle-nums；而font-feature-settings需手动合并字符串，易出错 -
font-feature-settings不受@supports检测友好支持（部分旧版 Safari 对它的@supports判断不准） - 现代项目应优先用
font-variant-numeric，仅在调试或需精细控制 OpenType 特性组合时才动font-feature-settings
示例等效写法：
code {
font-variant-numeric: tabular-nums;
}
/* 等价于 */
code {
font-feature-settings: "tnum";
}表格里带单位的数字还是不对齐怎么办
因为 tabular-nums 只作用于数字字符（U+0030–U+0039），对 "¥"、"%"、"kg"、"℃" 这类单位完全无效。混合内容强行套用该属性，等于只修了一半路。
真实可行的解法是结构分离：
- 把纯数字部分包进
<span class="num">，加font-variant-numeric: tabular-nums+ 显式等宽字体栈 - 单位部分用
<span class="unit">，设固定width（如2em）或统一padding-left+text-align: left - 负号要用 Unicode 减号
−（U+2212），不是短横-（U+002D）；后者不会随tnum对齐，需替换或用::before插入
HTML 示例：
<td><span class="num">−17</span><span class="unit">℃</span></td>
兼容性差的旧浏览器怎么兜底
Safari ≤15.3、Firefox ≤91、Chrome ≤102 会静默忽略 font-variant-numeric。不能指望它降级为比例数字——而是直接失效，数字列立刻参差。
渐进增强必须做两层：
- 第一层保底：用
font-family: monospace（哪怕粗糙，至少强等宽） - 第二层增强：用
@supports (font-variant-numeric: tabular-nums)包裹正式声明，确保只在支持环境生效 - 额外加固：给数字列加
table-layout: fixed和明确col宽度，防止内容撑开破坏对齐
不要省略 @supports 块——它能避免在不支持环境中多加载无用样式，也防止旧引擎因不认识属性而整条规则失效。
容易被忽略的一点：即使字体支持 tnum，如果页面用了 font-weight: bold 且该粗体变体未打包等宽数字字形，也会回退到比例数字。检查时得连同字重一起验证。
