结论是：vh/vw绑定浏览器窗口，%绑定父元素；必须用vh/vw的场景包括全屏高度（如100vh避免父高未设导致失效）、响应式字体（如5vw而非100%）、以及需脱离嵌套结构干扰的视口比例控制。
直接说结论：用 vh/vw 时，你绑定的是浏览器窗口；用 % 时，你绑定的是父元素。选哪个，取决于你想让尺寸“听谁的”。
什么时候必须用 vh/vw 而不能用 %
常见错误现象：写 height: 100% 却得不到全屏高度，页面留白或撑不开。
原因很简单：% 高度依赖父元素有明确高度（比如 html、body 没设 height: 100%，子元素的 100% 就是 0）；而 vh 不管父级有没有设高，100vh 永远等于当前可视区域高度。
- 全屏轮播图、登录页背景、弹窗遮罩层——优先用
100vh - 字体随屏幕宽度缩放（比如标题字号要占视口宽的 5%）——用
font-size: 5vw，不用%（因为%是继承父元素font-size，不是视口） - 需要精确控制某区域占视口比例（如导航栏固定占 8vh），且不希望被嵌套结构干扰——
vh/vw更可靠
为什么 % 在某些场景反而更安全
使用场景：组件内嵌、卡片布局、栅格系统内部尺寸控制。
立即学习“前端免费学习笔记（深入）”；
% 的优势在于“可预测的层级关系”。比如一个 .card 宽度设为 50%，它始终占父容器一半，不管父容器是 300px 还是 1200px；而 50vw 会永远占视口一半，哪怕父容器只有 200px 宽，它也会强行撑到 600px（假设视口宽 1200px），导致溢出。
- Flex/Grid 布局中子项的
flex-basis或grid-template-columns用%更易协同 - 表单控件、按钮组等需要与周围容器保持比例一致的 UI 元素，
%更利于维护视觉节奏 - 当组件会被复用在不同上下文中（比如同一个
.banner插入到窄 sidebar 和宽 main 区域），%表现更可控
vmin/vmax 解决了什么实际问题
典型错误：用 width: 100vw 做横屏适配，结果在小屏竖屏下文字挤成一团；或用 font-size: 6vw，在大屏上字大得离谱。
vmin 和 vmax 是对 vw/vh 的补充，不是替代。它们把“听谁的”从单一维度扩展到二维判断：
-
vmin取vw和vh中较小值，适合做“等比缩放容器”，比如图标容器要始终正方形且占视口最小边的 20%：width: 20vmin; height: 20vmin; -
vmax取较大值，适合做“全向拉伸”，比如背景图要完全覆盖可视区（无论横竖屏）：min-width: 100vmax; min-height: 100vmax; - 注意：iOS Safari 对
vmin/vmax的支持从 iOS 10+ 开始稳定，旧版需降级 fallback
真正容易被忽略的点是：视口单位受 viewport meta 设置影响。比如 content="width=device-width, initial-scale=1" 缺失时，100vw 可能对应的是缩放前的布局视口宽度，而非用户看到的视觉视口——这会导致计算偏差。所有用 vh/vw 的项目，第一步必须确认 <meta name="viewport"> 存在且正确。
