应使用无单位line-height（如1.5），因其按font-size倍数计算，可随字号缩放、继承可靠；配合rem字体和统一字体栈，能避免浏览器缩放或dpi变化导致的盒模型错位与基线偏移。
为什么font-size缩放会引发盒模型错位
浏览器缩放（Ctrl+/- 或系统DPI缩放）时，px单位的font-size、line-height、padding不会同比例变化——但它们共同决定元素高度和行内基线位置。比如font-size: 16px; line-height: 1.5;在125%缩放下，文字实际渲染变大，但line-height若用px（如line-height: 24px），可能被截断或挤压；若用无单位值（line-height: 1.5），它虽随字号缩放，却因字体度量差异（ascent/descent）导致不同字体间基线偏移，进而让inline-block或flex子项上下错位。
rem + 固定line-height组合为何更稳
用rem控制font-size本身不解决错位，关键在于它配合**无单位line-height** 和**统一字体栈**后，能确保所有文本块的行高计算基准一致：
-
html { font-size: clamp(14px, 2.5vw, 18px); }→ 根字号响应视口，避免固定16px在小屏过小、大屏模糊 -
body { font-size: 1rem; line-height: 1.5; }→line-height是乘数，随rem等比缩放，不依赖像素渲染精度 - 显式声明
font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", sans-serif;→ 避免Firefox/Safari回退到monospace造成行高突变
textarea和表单控件必须单独处理
textarea对rem和无单位line-height解析不稳定，尤其在iOS Safari中易丢继承、触发行高塌陷。不能复用全局规则：
- 必须显式设
font-size: 16px;（不用rem）和line-height: 1.4;（无单位，但需实测验证） - 强制
box-sizing: border-box;，且选择器要具体：textarea:not([readonly])比*更可靠 - 禁用
resize: none;，否则某些安卓WebView会误判可编辑区域高度
容易被忽略的基线对齐陷阱
即使font-size和line-height都用了rem，vertical-align默认值baseline仍会让图片、按钮、文字因字体基线差异而错位。这不是单位问题，而是渲染逻辑：
- 在
inline-block场景中，统一加vertical-align: middle;或top; - 在
flex容器中，align-items: center;比依赖line-height更可控 - 表格单元格（
td）需额外加vertical-align: top;，否则内容会因line-height撑高而下沉
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
