用 vh/vw 实现屏幕高度自适应可行，但移动端需处理地址栏收放导致的视口跳变；100vh 基于初始布局视口，不响应动态变化，易致截断或留白；推荐优先使用 100dvh（iOS 16.4+/Chrome 105+支持），旧版降级为 min-height: 100vh + JS 动态更新 --vh 变量。
直接说结论：用 vh 和 vw 实现屏幕高度自适应是可行的，但必须处理移动端地址栏收放导致的视口高度跳变问题，否则 100vh 在 Safari 或 Chrome 移动端会“错高”。
为什么 100vh 在手机上经常“不够高”或“太高”
移动端浏览器（尤其是 iOS Safari）的地址栏/工具栏会动态显示或隐藏，导致 window.innerHeight 变化，但 100vh 始终按初始布局视口（Layout Viewport）计算，而非用户当前看到的视觉区域。典型现象是：页面刚加载时内容被截断，下拉后突然多出空白；或固定底部按钮被地址栏盖住。
- 不要依赖
100vh做全屏容器高度，尤其在需要精确对齐或滚动锚点的场景 - 可用
100dvh替代（dynamic viewport height），它响应地址栏显隐，Chrome 105+、Safari 16.4+、Firefox 114+ 已支持 - 兼容旧版需降级：用
min-height: 100vh+ JavaScript 监听resize并更新style.height，但注意防抖
用 vh 设置高度时，哪些值最常用且安全
vh 单位适合控制与屏幕高度强相关的尺寸，但并非所有百分比都合理。例如 200vh 会强制两屏高，可能破坏滚动体验；10vh 在小屏上可能只剩 50px，文字难读。
- 推荐范围：
50vh～95vh之间较稳妥，如全屏 Banner 用80vh留白，登录框容器用70vh居中 - 避免硬写
100vh做html或body高度，这会干扰文档流，引发 margin 折叠或 flex 容器失效 - 配合
clamp()更健壮：height: clamp(400px, 80vh, 900px)，既保最小可读性，又防超大屏撑开
vw/vh 搭配字体和间距时的典型误用
很多人用 vw 写字体大小（如 font-size: 4vw），结果在桌面端字号爆炸，在小屏又过小。这不是单位本身的问题，而是没设边界。
- 单用
vw做响应式字体风险高，建议改用clamp(16px, 4vw, 32px) - 内边距慎用纯
vh：padding-top: 5vh在 iPhone SE 上仅约 12px，但在 iPad Pro 上达 45px，视觉失衡 - 更稳的做法：垂直方向用
vh控制容器，内部文字/按钮用rem或em，保持层级比例
要不要用 vmin/vmax？什么场景下值得切
vmin 和 vmax 不是“高级替代”，而是解决特定约束的工具。比如正方形卡片、等比缩放 logo、横竖屏统一适配。
- 做正方形元素：用
width: 50vmin; height: 50vmin;，比aspect-ratio: 1兼容性更好（IE 不支持 aspect-ratio） - 横屏优先的仪表盘：用
vmax控制关键指标字号，确保在 TV 或旋转手机时始终以较大边为基准 - 注意：
vmin在窄高屏（如折叠屏竖向）会按宽度算，可能比预期小；测试时务必用真实设备横竖切换验证
真正麻烦的不是单位怎么写，而是你是否意识到：视口单位生效的前提，是浏览器准确报告了视口尺寸——而这个“视口”，在不同平台、不同 UA、甚至同一浏览器的不同状态（全屏/非全屏/地址栏展开）下，根本就不是一个稳定值。所以别只盯着 CSS，先确认你的目标设备和浏览器版本是否真把 dvh 当一回事。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
