vw/vh 是视口单位，1vw=视口宽1%、1vh=视口高1%，不依赖父元素或字体大小；而%依赖父容器宽度，em依赖父元素font-size。
vw/vh 是什么，和百分比、em 有什么根本区别
vw/vh 是视口（viewport）单位，1vw = 视口宽度的 1%，1vh = 视口高度的 1%。它不依赖父元素尺寸，也不受字体大小影响——这点和 %（依赖父容器）、em（依赖父元素 font-size）完全不同。
这意味着：用 width: 50vw 的元素，不管嵌套多深、父容器是否设置了 width，它永远占屏幕宽的一半；而 width: 50% 可能因父容器是 display: flex 或 position: absolute 导致计算异常。
- 移动端适配中，
vh对全屏轮播、登录弹窗高度控制更可靠（但注意 iOS Safari 地址栏缩放会动态改变vh值） -
vmin/vmax更适合等比缩放场景，比如图标容器要始终在视口最小边的 20% 内：用width: 20vmin; height: 20vmin - 不要用
vh直接设<body>高度来“撑满屏幕”，滚动条出现后实际可视区域变小，100vh会溢出
常见误用：iOS Safari 中 100vh 被截断或跳动
iOS Safari 在地址栏收起/展开时会重算视口高度，导致 100vh 突然变大或变小，页面内容“抽搐”。这不是 bug，是浏览器真实行为。
解决思路不是禁用缩放，而是绕过动态 vh：
立即学习“前端免费学习笔记（深入）”；
- 用 JS 动态写入真实可用高度：
document.documentElement.style.setProperty('--vh', `${window.innerHeight * 0.01}px`);然后 CSS 中写height: calc(var(--vh, 1vh) * 100) - 对固定全屏模块（如 splash 页），改用
min-height: 100vh+height: 100%组合，让内容可自然撑开 - 避免给
<html>或<body>设height: 100vh，这会干扰 document 流布局
配合 rem + vw 实现字体响应式缩放
纯 vw 做字体（如 font-size: 4vw）在超大屏上会过大，超小屏又过小。更稳的做法是用 vw 控制根字号，再用 rem 定义具体文字：
:root {
font-size: calc(16px + 0.25vw);
}
h1 { font-size: 2rem; }
p { font-size: 1rem; }上面的 calc(16px + 0.25vw) 表示：基础 16px，每 100px 屏宽额外加 2.5px，兼顾小屏可读性与大屏视觉比例。
- 别用
font-size: 2vw直接写死，iPhone SE（375px）下是 7.5px，远低于可读下限 - 如果项目已用 postcss-pxtorem，需关掉对
vw值的转换，否则4vw可能被错误转成4rem - 搭配
clamp()更精细（如font-size: clamp(1rem, 2.5vw, 1.5rem)），但 IE 不支持
vw/vh 在 Flex/Grid 布局中的边界陷阱
当 vw/vh 用在 flex-basis 或 grid-template-columns 里，容易因容器未定义尺寸而失效。例如：
.container {
display: flex;
}
.item { flex-basis: 30vw; }如果 .container 没设 width 或没被父级约束，30vw 仍生效，但整个 flex 容器可能收缩到内容宽，造成布局错乱。
- Flex 容器建议显式设
width: 100%或max-width: 100vw，避免隐式收缩 - Grid 中慎用
1fr和50vw混用，比如grid-template-columns: 50vw 1fr——1fr会按剩余空间算，但50vw是绝对视口值，两者逻辑不匹配 - 动画中用
transform: translateX(100vw)比left: 100vw性能更好，且不受 position 上下文影响
真正难的不是写出 vw，而是判断什么时候该用它、什么时候该退回到 max-width + margin: auto 这类传统响应式手段。视口单位只解决“相对视口”的问题，不解决“内容层级关系”和“语义约束”。
