真正稳的全屏 hero 应用 min-height: 100vh + flex 居中 + 容器语义约束，而非 height: 100vh；因 ios safari 地址栏收放及安卓 webview 对 vh 解析不一致，导致高度跳变或渲染异常。
固定 height: 100vh 在 iOS Safari 和部分安卓 WebView 中会因地址栏收放导致高度跳变，真正稳的全屏 Hero 不靠“刚好填满”，而靠 min-height + flex 居中 + 容器语义约束。
为什么 height: 100vh 在移动端不可靠
iOS Safari 地址栏收起时视口高度突增，height: 100vh 会瞬间拉高容器，文字/按钮被顶出可视区；安卓某些 WebView 对 vh 解析不一致，可能渲染为 0。这不是 bug，是规范允许的行为——vh 基于初始视口，不响应滚动或 UI 变化。
改用 min-height: 100vh 能兜底：保证至少一屏高，但允许内容撑开（比如长文案+CTA），避免截断；再配合 flex 布局，文字始终在视觉重心位置，不随高度浮动。
-
min-height: 100vh是安全下限，不是强制锁定 - 必须给父级
html和body加height: 100%，否则vh单位在子元素里可能失效 - 若 Hero 内含视频或大图，加
overflow: hidden防止滚动条意外出现
Flex 居中文字层的实际写法与陷阱
用 flex 居中比 absolute + transform 更健壮，但容易漏掉关键约束：
- 父容器必须设
display: flex; flex-direction: column; justify-content: center; align-items: center; - 文字容器本身不要设
height，否则在小屏上会挤压背景图留白；让它自然包裹内容 - 如果文字层在 iPad 横屏（1024×768）下盖住产品主体，说明垂直居中太“死板”——改用
justify-content: flex-start+padding-top: 20%（相对父高）更可控 - 别用
margin-top: auto代替justify-content，它在 flex 容器中行为不稳定，尤其在 Safari 中
背景图适配必须搭配 object-fit 工具类
Tailwind 的 bg-cover 只控制 background-size，不等价于图片的 object-fit；真正决定构图是否被切掉的是 object-center 或 object-top 这类工具类（注意不是 bg-center，那是背景定位）。
- 人脸/产品主体在图上方？用
object-top+bg-[center_top]双保险 - 图本身宽高比失衡（如 4:1 横幅图），
object-center比默认的object-top更不容易切头 - 降级底色必须设，例如
bg-gradient-to-b from-gray-900/80 to-gray-900，否则图片加载失败时文字直接糊在白底上 - 不用
bg-blend-multiply做文字可读性保障——它依赖图片存在，失败时文字完全不可读
小屏下留白失控？用 aspect-ratio 锁比例
单纯 min-height: 100vh 在手机竖屏下可能让 Hero 区域过高（比如 812px 高度），文字离顶部太远。此时不靠媒体查询硬调 padding，而是用 CSS 新特性锚定视觉节奏：
- 给 Hero 容器加
aspect-ratio: 16 / 9，它会优先保持比例，再按min-height扩展 - 搭配
background-size: cover，裁剪更可预测，不会因设备差异突然切掉关键区域 - 旧浏览器不支持
aspect-ratio？用padding-top: 56.25%（16:9 的百分比）+position: relative+ 子元素position: absolute兜底 - 别在
@media (max-width: 768px)里把min-height改成50vh——这会让小屏用户必须滚动才能看到 CTA 按钮
最常被忽略的一点：Hero 区域的语义边界必须清晰。它不该是 section 里一个无高度的空 div，而应有明确的 min-height、background 和 flex 上下文——否则在组件化开发中，父级容器塌陷会导致整个布局错乱，且无法被屏幕阅读器正确识别。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
