混用 font-size 的 % 和 px 会破坏继承链，导致字体大小计算失控；应锚定根字号，组件内用 em/% 缩放，line-height 必须用无单位值。
font-size 百分比和 px 混用会破坏继承链
百分比（%）和像素（px）混用本身不报错，但会导致字体大小计算不可预测——尤其在嵌套结构中。因为 % 始终相对于父元素的 font-size，而 px 是绝对值，一旦父级用了 px，子级用 120% 就变成 “120% × 固定像素”，后续再嵌套一层 em 或 %，就容易放大/缩小失控。
- 常见错误现象：同一段 CSS，在 Chrome 看正常，Safari 里文字突然变小；或某组件内文字莫名缩到 10px
- 根本原因：浏览器对
%的解析严格依赖父级最终渲染出的font-size值，而该值可能来自px、rem、甚至用户系统设置，混用等于放弃控制权 - 真实场景：比如全局设了
body { font-size: 14px; }，又在某个卡片里写.card { font-size: 90%; }，再在里面加个按钮.btn { font-size: 0.85em; }→ 实际是14px × 0.9 × 0.85 ≈ 10.71px，但开发者以为只是“比按钮默认小一点”
统一单位的关键不是“全换 px”，而是锚定基准
强行把所有 % 改成 px 只会让响应式失效；全换成 rem 又可能忽略局部缩放需求。真正要做的，是明确「谁负责定义基准」、「谁负责相对调整」。
-
html元素设根字号（推荐font-size: 100%或16px），这是所有rem和%的起点 - 组件内部用
em或%进行比例缩放（如标题是正文的 1.5 倍），但前提是父容器已用rem或显式px设好基础值 - 避免在同一个选择器里混写
font-size: 14px / 120%—— 浏览器只认一个值，后者会覆盖前者，但开发者常误以为是叠加
calc() 是唯一安全的 px + % 混合方式
如果真需要“基础像素 + 百分比弹性”，必须用 calc()，它在语法层就强制分离计算逻辑，且现代浏览器支持率已达 99%+（包括 iOS Safari 13.4+）。
/* 安全：明确表达“最小 14px，再加视口宽度的 0.2%” */
.text-primary {
font-size: calc(14px + 0.2vw);
}
<p>/<em> 错误：下面这行等价于只生效 120%，前面的 14px 被忽略 </em>/
.bad-example {
font-size: 14px;
font-size: 120%;
}-
calc(14px + 10%)❌ 不合法 ——%在这里无参照物（不是 width/height，没有父容器宽高上下文） -
calc(14px + 0.2vw)✅ 合法 ——vw是视口单位，有明确定义 - 若非要基于父宽，得用 JS 动态注入或 CSS 自定义属性配合
attr()（目前支持有限），不建议
line-height 也得跟着统一单位逻辑走
很多人改完 font-size 却忘了 line-height，结果文字挤在一起或行距爆炸。关键规则只有一条：line-height 必须用无单位数值（如 1.5），否则它会继承并二次计算。
立即学习“前端免费学习笔记（深入）”；
.content {
font-size: 1.125rem; /* = 18px（假设 root=16px） */
line-height: 1.5; /* ✅ 行高 = 18px × 1.5 = 27px */
}
<p>.bad-line-height {
font-size: 1.125rem;
line-height: 24px; /<em> ❌ 小屏下 24px 行高 > 字号，显得空；大屏下又太紧 </em>/
}- 用
px写line-height：失去弹性，跨设备易失衡 - 用
em或%写line-height：会层层相乘，三层嵌套后可能是预期的 1.5³ 倍 - 唯一可靠的是无单位数字 —— 它始终是当前
font-size的倍数，不随单位切换偏移
百分比和 px 混用不是语法错误，而是设计断层。真正难的不是写对一行代码，而是让整个字体系统里每个 em、rem、% 都知道它的“爸爸”是谁。
