100vh在移动端“不够高”是因为其基于初始视口高度静态计算，不响应地址栏收起/展开或键盘弹出导致的可视区域动态变化；应优先使用100dvh（chrome 100+/safari 16.4+/firefox 112+支持），并配合@supports降级至100vh。
vw 和 vh 不是“更高级的百分比”，它们直接锚定浏览器可视区域，能绕过父容器限制实现真视口级缩放——但盲目替换 % 或 px 往往导致移动端错位、字体抖动或高度塌陷。
为什么 100vh 在手机上经常“不够高”？
移动端浏览器地址栏会动态收起/展开，vh 基于的是初始视口高度（vh），不是用户当前看到的可用空间。常见现象：页面底部被截断、固定定位元素错位、滚动条意外出现。
- 优先改用
dvh（dynamic viewport height）：它始终反映用户当前可见区域高度，Chrome 100+、Safari 16.4+、Firefox 112+ 已支持 - 降级方案：用 JavaScript 监听
resize并更新style.height，但需防抖避免重排 - 简单兼容写法：
height: 100dvh; height: 100vh;—— 后者仅在不支持dvh的旧浏览器生效
font-size 用 vw 时为什么文字忽大忽小？
纯 font-size: 5vw 在小屏（如 320px 宽）下会缩到 16px 以下，可读性崩坏；在超宽屏（如 3840px）下可能撑到 192px，破坏布局节奏。
- 必须搭配
clamp()：例如font-size: clamp(1rem, 4.5vw, 2.5rem)，明确最小、理想、最大值 - 避免用
vw设置行高（line-height）：它会随字号放大，但行距不需要同比例增长，易造成段落拥挤 - 慎用
em或rem混合：若根字体用vw动态设置，子元素再用em会叠加缩放，失控风险高
如何用 vmin/vmax 解决横竖屏适配矛盾？
当设计要求“元素始终占满屏幕短边”或“按长边拉伸背景图”时，vw/vh 单独用会失效。
-
vmin适合图标、按钮等需要“最小可见尺寸”的控件：width: 12vmin; height: 12vmin;—— 在 iPhone 竖屏（390×844）下取 390px 的 12% ≈ 47px，在横屏（844×390）下仍取 390px 的 12%，保持视觉一致性 -
vmax适合全屏背景图裁剪：width: 100vmax; height: 100vmax; object-fit: cover;确保图像始终覆盖整个可视区域，不露白边 - 注意：
vmin和vmax在部分 Android WebView（尤其旧版）中支持度弱于vw/vh，需测试 fallback
哪些场景不该用 vw/vh？
它们不是万能替代品，强行套用反而增加维护成本。
- 表单控件（
input、select）：系统级 UI 对像素尺寸敏感，16px是触摸目标最小推荐值，2vw在小屏可能低于 6px - 边框（
border-width）：用px保证清晰度，0.1vw在 1920px 屏幕下是 1.92px，渲染模糊 - 栅格间距（
gap）：建议用rem或固定px，1vmin在桌面端可能过小（如 1920×1080 下仅 10.8px） - 动画关键帧中的位移值：
transform: translateX(50vw)在滚动时可能因视口变化跳变，应改用50%或 JS 控制
width: 100vw，而是判断它该不该存在、在哪一层生效、是否被父容器的 overflow: hidden 截断、有没有被 transform 或 position: fixed 改变参考系——这些细节不调试就永远看不见。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
