错位主因是line-height用了带单位的值（如24px）或字体栈不统一，导致缩放时行高与基线不同步；应改用无单位line-height（如1.5）并统一font-family。
直接说结论：错位主因不是单位选错了，而是 line-height 用了带单位的值（如 24px），或字体栈不统一，导致浏览器缩放时行高与文字基线不同步。用 rem 本身不防错位，关键在怎么配。
为什么 font-size 缩放会扯歪整个盒模型
浏览器缩放（Ctrl/Cmd + 或系统 DPI 调整）时，font-size 会变大，但如果你写的是 line-height: 24px，它不会跟着同比例放大；而 padding、border、height 等若也用 px，就和文字“脱节”了——结果就是文字撑高容器、内联元素上下错位、inline-block 对不齐。
更隐蔽的是字体度量差异：不同字体的 ascent/descent 不同，哪怕字号和 line-height 一样，基线位置也可能偏移。Safari 和 Firefox 在回退到 monospace 时尤其明显。
解决思路不是“换单位”，而是让所有影响高度的属性都按同一比例缩放，并锁定字体基准：
-
line-height必须用无单位值（如1.5），它才真正随font-size等比缩放 -
font-size用rem，但根字号不能写死html { font-size: 16px }（会覆盖用户可访问性设置） - 显式声明
font-family，避免浏览器随机回退：例如font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", sans-serif
textarea 和表单控件为什么 rem 失效
iOS Safari 对 textarea 的 rem 解析极不稳定——它可能丢掉继承、忽略 line-height、甚至在键盘弹出后重算失败，导致行高塌陷、文字被截断。
这不是 bug，是 WebKit 渲染层对表单控件的特殊处理。必须单独兜底：
- 给
textarea显式设font-size: 16px（不用rem），再配line-height: 1.4（无单位，实测调优） - 加
box-sizing: border-box，且选择器要具体，比如textarea:not([readonly])，别靠通配符 - 禁用
resize: none，某些安卓 WebView 会误判可编辑区域高度，引发滚动错位
vertical-align 和 flex 对齐为什么还错位
即使 font-size 和 line-height 都用对了，vertical-align: baseline（默认值）仍会让图片、按钮、文字因字体基线差异而上下偏移——这不是单位问题，是渲染逻辑本身。
常见翻车场景：inline-block 图标+文字、table td 里塞按钮、flex 容器中混用不同字体文本：
- 在
inline-block场景中，统一加vertical-align: middle或top，别依赖 baseline - 在
flex容器中，优先用align-items: center，它比靠line-height撑高更可控 -
td元素需额外加vertical-align: top，否则内容会被line-height撑高后“下沉”
媒体查询里用 rem 断点为什么有时不触发
在 iOS 12 及更早 Safari、旧版 Android WebView 中，@media (min-width: 40rem) 的 rem 是按当时已生效的 html 字号计算的——如果 JS 动态注入 CSS 或根字号还没加载完，这个 rem 就可能解析为 0，断点直接失效。
这不是你代码写错了，是解析时机不可控。稳妥做法：
- 所有媒体查询断点统一用
em（它在 MQ 中始终相对于浏览器默认字号 16px，稳定）或px（断点本就不该随字体缩放） - 如果坚持用
rem，确保html { font-size }在 CSS 文件最顶部声明，且不被 JS 延迟覆盖 - 测试时别只看 Ctrl+，更要开系统「更大字体」或「粗体文本」辅助功能——这种场景下，很多 rem 断点会静默失效
最容易被忽略的其实是 textarea 和 vertical-align 的组合陷阱：它们不报错、不警告，只在特定设备+缩放+输入法弹出时悄悄错位，上线后用户截图投诉才暴露。真要压测，得开着系统辅助功能，在横屏/竖屏/键盘弹起三连切下跑一遍。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
