直接用min-h-[100dvh]替代min-h-screen并配@supports降级和flex布局，是最轻量可靠的解法；裸写height:100vh或仅兜底不包裹规则会导致safari和微信webview彻底失效。
直接用 min-h-[100dvh] 替代 min-h-screen，并配合 @supports 降级和 flex 布局约束，是当前最轻量、最可靠的解法；裸写 height: 100vh 或只加兜底值不包裹规则，反而会让 Safari 和微信 WebView 彻底失效。
为什么 min-h-screen 在 iOS 和微信里会塌成一条线
它编译为 min-height: 100vh，而 iOS Safari（15.x 及更早）、微信 X5 内核根本不会动态更新 vh 值：页面加载时按物理屏高算（比如 812px），但地址栏收起后视口变大，100vh 却卡在旧值上，导致内容被裁切或底部留白。键盘弹出时同理——vh 不变，容器高度却“缩水”。
-
min-h-screen在 SSR 渲染中还可能因服务端无window对象而 fallback 为空，首屏直接无高度 - Android 部分 WebView（如华为、UC）甚至忽略整个
100vh声明，样式完全不生效 - 哪怕你写了
min-h-screen flex-1，若父容器没flex flex-col，flex-1就没空间可分，主区域照样塌陷
怎么正确用 min-h-[100dvh] 并兼容老环境
100dvh 是动态视口单位，随地址栏、键盘伸缩实时变化，iOS 16.4+、Chrome 109+ 已稳定支持。但它不能裸用，必须靠 @supports 控制生效范围：
- 错误写法：
.page { min-height: 100vh; min-height: 100dvh; }→ 老 Safari 忽略第二行，新 Safari 仍走第一行 - 正确写法：
.page { min-height: 100vh; } @supports (min-height: 100dvh) { .page { min-height: 100dvh; } }→ 兜底在外，新特性在内 - Tailwind 中需启用 arbitrary value 支持（v3.3+ 默认开启），直接写
min-h-[100dvh]即可 - 构建工具如 PostCSS 若自动把
dvh降级为vh，必须关掉该插件（例如postcss-100vh-fix）
绝对定位元素（遮罩层、侧边栏）为啥设了 min-h-[100dvh] 还没反应
百分比高度（包括 100dvh）依赖包含块（containing block）的高度，不是“强制占满屏幕”。常见于 fixed 弹窗、抽屉菜单、底部按钮等场景：
- 父容器（如
body或直接祖先）没设min-h-[100dvh]或显式高度 → 子元素的100dvh实际计算为0 - 别对
position: absolute/fixed元素用height: 100dvh，改用top-0 bottom-0更可靠（它不依赖父容器高度） - 侧边栏用
fixed时，必须加inset-y-0 left-0，而不是仅inset-0，避免 RTL 或其他定位干扰 - 若父容器本身也靠 JS 注入的
--vh驱动，需确保初始化完成后再渲染子元素，否则读到的是初始1px
必须搭配的布局约束和容易漏掉的细节
min-h-[100dvh] 只设最小高度，不自动触发弹性分配。要让主内容区撑满剩余空间，必须加布局约束：
- 根容器必须加
flex flex-col，否则flex-1无参照高度 - 主内容区加
flex-1 min-w-0（min-w-0防止长文本撑宽，iOS Safari 尤其需要） - 底部固定区域（如提交按钮）加
flex-shrink-0，否则键盘弹出会压缩它 - 删掉
html或body上的h-full/min-h-full，它们会干扰dvh行为 -
viewportmeta 必须干净：<meta name="viewport" content="width=device-width, initial-scale=1.0">，禁用maximum-scale=1或height=device-height（后者会让所有vh类失效）
真正容易被忽略的是：即使用了 100dvh，也要检查父容器是否参与高度继承链；而一旦引入 JS 动态方案，requestAnimationFrame 防抖和 DOMContentLoaded 后首次同步执行这两个点，漏掉任何一个都会导致首屏白屏或滚动跳变。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
