vw/vh 是基于视口宽高的相对单位，1vw=视口宽1%，1vh=视口高1%，不依赖父元素；% 相对于父元素，px 是绝对单位；vw/vh 适合全屏布局但需注意 iOS Safari 的 vh 跳变问题及字体失控风险。
vw/vh 是什么，和 %、px 有什么本质区别
vw 和 vh 是基于视口（viewport）尺寸的相对单位：1vw = 视口宽度的 1%，1vh = 视口高度的 1%。它不依赖父容器，只认 document.documentElement.clientWidth 和 document.documentElement.clientHeight。
-
%是相对于父元素的宽/高，嵌套深了容易失控 -
px是绝对单位，缩放或不同设备下表现僵硬 -
vw/vh始终锚定屏幕，适合全屏布局、响应式卡片、适配刘海屏等场景
注意：vh 在 iOS Safari 中可能因地址栏收放导致视口高度跳变，真实高度未必等于 window.innerHeight。
移动端用 vh 做全屏高度时，为什么内容被截断或滚动条出现
这是 iOS Safari 的经典问题：地址栏收起时 vh 按“最大可用高度”计算，但页面渲染时地址栏可能还占着空间，导致 100vh 实际大于可视区域。
常见错误写法：
立即学习“前端免费学习笔记（深入）”；
section { height: 100vh; }解决方式有二：
-
用 JavaScript 动态设置（兼容性好）：
document.documentElement.style.setProperty('--vh', `${window.innerHeight * 0.01}px`);然后在 CSS 中：section { height: calc(var(--vh, 1vh) * 100); }并监听resize事件更新 -
或改用
dvh（2023 年后支持渐广）：section { height: 100dvh; }dvh（dynamic viewport height）专为解决此问题设计，但 Android Chrome 104+、Safari 16.4+ 才支持，旧版本需降级
vw/vh 做字体大小时，为什么文字忽大忽小、阅读体验差
直接写 font-size: 4vw 看似灵活，实则危险：
- 在超宽屏（如 3840px）下，
4vw= 153.6px，远超可读上限 - 在小屏（如 320px）下，
4vw= 12.8px，太小看不清
这不是单位问题，是缺乏约束。正确做法是搭配 clamp()：
p { font-size: clamp(1rem, 2.5vw + 0.5rem, 1.5rem); }含义：最小 1rem，最大 1.5rem，中间按视口宽度线性插值。其中 2.5vw + 0.5rem 是弹性基准，可根据设计稿调整系数。
别忘了设置根字号基准：
html { font-size: 100%; }
否则某些浏览器会因用户缩放导致 rem 偏移，影响 clamp 计算。
用 vw/vh 布局时，如何避免与媒体查询冲突
很多人同时写：
@media (max-width: 768px) { .card { width: 90vw; } }.card { width: 30vw; }这看似“兜底”，实则容易覆盖失效——因为 vw 规则优先级不变，而媒体查询只是条件生效，并不提高选择器权重。
更稳妥的做法是：
-
把
vw当作“基础弹性”，媒体查询里只做关键断点修正，比如：.hero { width: 80vw; max-width: 1200px; } @media (max-width: 480px) { .hero { width: 95vw; max-width: none; } } 避免在媒体查询中重复定义同一属性的
vw值（如从30vw改成80vw），容易误判缩放临界点如果需要精确控制多端比例，优先考虑
container queries（配合inline-size），而非强行用vw模拟
实际项目里，vw/vh 最适合解决“锚定屏幕”的需求，而不是替代所有响应式逻辑。用得越泛，越难收口。
