vw/vh 常被误用因忽略滚动条宽度导致横向滚动、iOS Safari 中 vh 不实时更新引发页面跳动、纯 vw 字体在横屏时过大，应结合 vmin/vmax、clamp()、calc() 及布局上下文谨慎使用。
vw/vh 单位在移动端适配中为什么常被误用
vw/vh 是相对于视口宽度/高度的百分比单位，1vw = 1% of document.documentElement.clientWidth，1vh = 1% of document.documentElement.clientHeight。但很多人直接用 100vw 做全宽容器，结果在 iOS Safari 或某些 Android 浏览器里出现横向滚动条——这是因为 100vw 包含了垂直滚动条宽度（通常 16px），而视口宽度计算时未扣除它。
- 避免用
width: 100vw替代width: 100%，除非你明确需要撑满整个视口（含滚动条占位） - 做全屏背景图或遮罩层时，
width: 100vw; height: 100vh;是安全的；但做内容区域时优先用100%或flex: 1 - iOS Safari 中
vh在地址栏收起/展开时不会实时重算，导致“页面跳动”，可用 JS 动态设置style.setProperty('--vh', `${window.innerHeight * 0.01}px`)配合calc(100vh)替代
vmin/vmax 解决横竖屏切换时的字体缩放问题
单纯用 vw 控制字体大小，在手机横屏时可能让文字过大（比如 font-size: 5vw; 在横屏下等效于 180px），而 vmin 和 vmax 能自动取视口宽高中较小/较大者，更适合响应式排版。
-
font-size: 4vmin;表示字体始终是视口短边的 4%，竖屏时按宽度算，横屏时按高度算，视觉尺寸更稳定 - 搭配
clamp()效果更好：font-size: clamp(16px, 4vmin, 24px);，既防过小也防过大 - 注意：IE 完全不支持
vmin/vmax，如需兼容，得用媒体查询 fallback
使用 calc() 混合视口单位与固定值的典型场景
视口单位不能单独解决所有布局需求，常需和 px/em/rem 混合。例如顶部导航栏固定高 60px，剩余区域填满屏幕——这时不能只写 height: calc(100vh - 60px) 就完事。
- 必须确保父容器没有 padding/margin 干扰，且自身
box-sizing为border-box - 若父元素有
border或padding，要一并减去：height: calc(100vh - 60px - 2px - 1rem) - 在 Flex/Grid 布局中，
calc(100vh - 60px)可能被 flex 容器的min-height截断，建议同时设min-height: 0防止收缩失效
body {
margin: 0;
}
header {
height: 60px;
}
main {
height: calc(100vh - 60px);
min-height: 0; /* 关键：防止 flex item 收缩异常 */
}视口单位在 CSS Grid 中的实际限制
CSS Grid 的 grid-template-rows 和 grid-template-columns 支持 vw/vh，但浏览器对它们的解析逻辑和 Flex 不同——尤其是当网格容器本身高度未明确时，1fr 和 50vh 可能产生冲突。
立即学习“前端免费学习笔记（深入）”；
- 不要在同一个
grid-template-rows里混用vh和fr（如50vh 1fr），部分浏览器会忽略fr分配逻辑 - 若需固定头部+自适应主体，推荐用
grid-template-rows: 60px 1fr，而非60px calc(100vh - 60px) -
vh在嵌套 grid 中不会继承父 grid 的“可用高度”，它永远基于最外层视口，这点和 % 单位完全不同
视口单位不是万能的弹性方案，它的“绝对性”（始终锚定视口）恰恰是很多布局 bug 的源头。真正难的不是怎么写 100vw，而是判断什么时候不该用它。
