vw/vh 的参考对象是视口而非父元素，1vw=视口宽1%、1vh=视口高1%，与依赖父级的%单位本质不同，适用于全屏布局和响应式字体，但需注意iOS Safari的vh跳变及缩放行为差异。
vw/vh 的参考对象是视口，不是父元素
这是最常被误解的一点：写 width: 50% 是拿父容器的宽度当 100%，而 width: 50vw 是拿整个浏览器可视区域（viewport）的宽度当 100%。哪怕父元素只有 200px 宽，50vw 依然可能是 960px（在 1920px 宽屏幕上）。
常见错误现象：
- 用
%设高度时子元素不显示——因为父容器没设height，百分比高度失效；但50vh永远有效，它不依赖父级 - 在移动端横竖屏切换时，
font-size: 4vw字体会明显变大/变小，而font-size: 100%只随父元素字体变化，跟屏幕方向无关
使用场景建议：
- 全屏 banner、登录页背景图高度：直接用
height: 100vh，不用再给html、body设高 - 响应式字体：配合
clamp()限制极值，比如font-size: clamp(16px, 4vw, 24px)
% 在 height 上容易失效，vh 不会
% 对 height 的计算依赖父容器显式设置高度，否则会被当成 0；vh 则完全绕过这层依赖，直接读取视口当前高度值。
立即学习“前端免费学习笔记（深入）”；
典型踩坑路径：
Convert Markdown To HTML And PDF - Markdown和HTML、PDF互转
下载
实现 Markdown↔ HTML 互转，支持导出 PDF，用于用户请求的文档格式转换。
- 写
.container { height: 100%; }→ 父级body没设高 → 实际渲染高度为 0 - 加
html, body { height: 100%; }→ 有时仍无效（比如 body 有 margin 或被重置） - 改用
.container { height: 100vh; }→ 一步到位，稳定生效
注意兼容性：IE10+ 支持 vh，但 IE11 对 100vh 有 bug（含地址栏时会多出几像素），需用 100dvh 替代（Chrome 105+/Safari 16.4+/Firefox 110+ 支持）
vw/vh 和 % 在缩放行为上根本不同
浏览器缩放（Ctrl + / Cmd +）时：% 值按比例重算，但参考的父容器尺寸也同步缩放，视觉上“相对关系”保持；而 vw/vh 是基于视口物理像素计算的，缩放后视口尺寸不变，所以 50vw 对应的像素数也不变——看起来就像“固定大小”。
这意味着：
- 用
vw做按钮宽度，在用户缩放到 125% 时，按钮不会变宽，可能显得拥挤 - 用
%做栅格系统，在缩放时列宽比例不变，更符合传统布局预期 - 做适配移动端的流体排版，
vw更适合控制整体节奏（如标题占满视口 80% 宽），%更适合内部微调（如按钮占父容器 80% 宽）
rem/em/%/vw/vh 混用时的基准混乱风险
一个元素同时用了 font-size: 1.5rem、padding: 2vh、margin: 5%，三者基准完全不同：rem 看根字体、vh 看视口、% 看父宽。视觉节奏容易断裂。
实操建议：
- 统一基准优先级：比如全局用
html { font-size: calc(16px + 0.25vw); }+rem，比混用vw和%更可控 - 避免在同一个组件内交叉使用
vh和%控制高度，尤其当该组件会被嵌套进不同高度的容器中 - 调试时用浏览器开发者工具的「Computed」面板看最终像素值，别只信 CSS 面板里写的单位
真正难的不是记住每个单位怎么算，而是判断哪个场景下该放弃“绝对精确”，转而接受视口单位带来的天然弹性——比如你不需要按钮永远是 120px 宽，只需要它在手机上够点、在桌面够看，那 15vw 可能比 120px 或 60% 更合适。
