cap定理指出分布式系统中一致性、可用性、分区容忍性三者不可兼得，最多满足其二；其核心在于网络分区发生时必须在一致性和可用性间权衡，分区容忍性则是分布式系统的必然要求。
cap 单位在实际项目中极少被直接使用，不是它没用，而是浏览器支持刚稳定不久（Chrome 120+、Firefox 115+、Safari 17.4+），且容易被误读为“字符高度”或和 em/ex 混用——它只代表当前字体中大写字母的**名义高度（cap height）**，不等于 font-size，也不随小写字母变化。
cap单位怎么算出来的？看字体本身
cap 不是浏览器“猜”的，而是从当前使用的字体文件里提取的字体度量值（OS/2 table 中的 sCapHeight 字段）。这意味着：
- 同一
font-size下，不同字体的1cap实际像素值可能差 10% 以上（比如 Inter 和 Roboto 的 cap 高度就不同） - 如果字体未加载完成或回退到系统字体，
cap值会按回退链中第一个可用字体重新计算，可能导致布局跳动 - Web Font 必须启用
font-display: swap或optional，否则 FOUT 期间cap可能为 0 或 fallback 值
哪些场景适合用 cap 而不是 em/rem？
当你需要让某元素严格对齐大写字母顶部（比如下划线、装饰横线、图标 baseline 对齐），又不想硬写像素值时，cap 才有不可替代性。典型例子：
- 标题下方一条紧贴大写字母顶部的细线：
border-bottom: 1px solid #000; padding-bottom: 0.1cap; - 图标容器高度刚好容纳大写字母区域：
height: 2.2cap;（比2em更精准控制垂直空间） - 与大写文本并排的 badge，用
line-height: 1cap;让文字垂直居中更稳（比line-height: 1;更少受 x-height 干扰）
cap 和 ch/em/ex 混用时的常见错误
开发者常把 cap 当成“大写版的 ex”，但它们来源完全不同：
-
ex来自字体的 x-height（小写字母 x 的高度），而cap是大写字母 H 或 I 的顶部高度，二者无固定比例 -
ch是 “0” 字符宽度，和cap没有几何关联；用width: 5ch; height: 3cap;是合法的，但别假设它们能构成正方形 -
1cap≠1em：多数字体中cap约为0.7–0.85em，硬写font-size: 1cap;会导致文字显著变小（因为font-size属性本身不接受cap作为单位）
真正要用好 cap，得先确认目标字体是否导出了准确的 sCapHeight（可用 opentype.js 或 fonttools 检查），再在 CSS 中用 @supports (height: 1cap) 做渐进增强——毕竟它还不是所有旧版浏览器都认的单位。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
