100vh在手机上被截断是因为它锁定初始视口高度，不随safari/chrome地址栏收起或软键盘弹出动态更新，导致布局错位；应优先用100dvh并降级回100vh，或js动态注入--vh变量。
100vh 在手机上为什么总被截断
因为 100vh 锚定的是页面加载时的初始视口高度，不是用户当前看到的可用区域。Safari 和 Chrome 移动版在地址栏收起/展开、软键盘弹出时会动态改变可视高度，但 100vh 不重算，导致容器“太高”或“太矮”。
常见现象包括：固定定位按钮错位、轮播图底部露白、滚动条意外出现、position: fixed 元素被遮挡。
- 优先改用
100dvh（Chrome 100+ / Safari 16.4+ / Firefox 112+ 支持） - 降级写法必须按顺序：
height: 100dvh;后紧跟height: 100vh;，CSS 解析器会忽略不支持的前项 - 若需兼容更老环境，用 JS 动态注入：
document.documentElement.style.setProperty('--vh', `${window.innerHeight * 0.01}px`)，再在 CSS 中写height: calc(var(--vh, 1vh) * 100)
font-size: 5vw 为什么会让文字忽大忽小甚至糊成一片
5vw 是纯线性缩放，无视可读性底线：iPhone 竖屏（375px）下仅 18.75px，横屏（812px）下飙到 40.6px；而 iPad Pro 横屏（2048px）直接冲到 102.4px——标题顶到屏幕边，正文行宽爆炸，阅读效率归零。
更糟的是，小屏下 1vw 可能算出 3.2px，浏览器虽强制升至 12px，但比例关系已崩坏；vh 还会因地址栏变化引发文字跳动。
- 正文首选
clamp(16px, 4vmin, 24px)：最小 16px 防糊眼，最大 24px 防撑爆，中间用vmin保证横竖屏视觉一致 - 标题可用
calc(1.5rem + 2vw)，基准稳、增量柔，比纯5vw更收敛 - 绝对不要对
line-height用vh或vw：它应基于字号本身（如line-height: 1.4），否则小屏行距塌陷、大屏撕裂
vmin/vmax 比 vw/vh 更适合哪些场景
当设计要求“视觉尺寸稳定”，而非“按宽度或高度单向缩放”时，vmin 和 vmax 才是真解。比如图标按钮在 iPhone 竖屏（390×844）和横屏（844×390）下都该保持约 47px，而不是一个 39px、一个 84px。
vmin 取 vw 和 vh 的较小值，天然适配短边主导的 UI 控件；vmax 取较大值，适合全屏背景图裁剪这类“必须覆盖整个可视区域”的需求。
- 图标/按钮尺寸：
width: 12vmin; height: 12vmin; - 全屏背景图：
width: 100vmax; height: 100vmax; object-fit: cover; - 注意 Android WebView（尤其旧版）对
vmin/vmax支持弱于vw/vh，上线前务必真机测试 fallback 行为
哪些地方死都不能用 vw/vh
它们不是万能响应式银弹。强行套用会破坏基础交互体验，且难以调试。
-
input、select等表单控件：系统级渲染依赖像素精度，2vw在小屏可能低于 6px，触摸目标远低于 WCAG 推荐的 44×44px 最小尺寸 -
border-width：用px保清晰，0.1vw在 1920px 屏上是 1.92px，渲染模糊 -
gap（Grid/Flex 间距）：建议用rem或固定px，1vmin在桌面端可能过宽，移动端又过窄
最常被忽略的一点：给 或 直接设 height: 100vh，会干扰 document 流布局，导致滚动异常或子元素 height: 100% 失效——这种写法几乎总是错的。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
