应使用 100dvh 配合 @supports 和 min-height 解决 safari 响应式菜单高度问题，而非 -webkit-fill-available；需添加 max-height 媒体查询、overflow-y: scroll 及修正 footer 定位，并检查 pointer-events、img 尺寸和 overflow:hidden 等隐藏陷阱。
别用 -webkit-fill-available 修 Safari 下响应式菜单高度问题——它根本不管用，还可能让布局更糟。
为什么 -webkit-fill-available 在 height 上完全不可靠
这个值不是为容器高度设计的：它是 WebKit 内部给 <input> 这类表单控件预留的填充逻辑，硬套在 height 上属于误用。
- iOS Safari 对
height: -webkit-fill-available支持极不稳定，某些版本直接退化成auto，触发意外重排 - 它和
100vh一样“冻结”在页面加载瞬间，地址栏收起后高度不会更新 - Chrome / Android WebView 完全不识别该值用于
height，声明直接被忽略 - 即使看起来“撑开了”，也只是巧合——背后没标准、没语义、无保障
真正该用的是 100dvh，但必须配 @supports 和 min-height
100dvh 是唯一语义正确、浏览器原生响应可见区域变化的高度单位，iOS 16.4+、Chrome 105+、Firefox 112+ 全已支持。
- 必须用
min-height，不能用height：防止内容超长时被裁剪 - 必须包裹在
@supports (min-height: 100dvh)里：否则 iOS 15 及更早版本会整条规则失效 - 声明顺序要对：
min-height: 100vh写在前，@supports块内覆盖它，老浏览器自然 fallback - 不能用于
@media查询条件（如@media (min-height: 100dvh)无效）
正确写法：
.menu-overlay {
min-height: 100vh;
}
@supports (min-height: 100dvh) {
.menu-overlay {
min-height: 100dvh;
}
}
小高度视口（比如手机横屏）下菜单仍出问题？加 max-height 媒体查询
当设备横置，视口高度可能只剩 320–450px，100dvh 虽然准确，但固定高 + 绝对定位页脚仍会导致内容溢出或页脚错位。
- 对
#menu-general加overflow-y: scroll，确保可滚动访问全部内容 - 把
.menu-footer的position从absolute改成relative，让它随内容自然流式排列 - 媒体查询临界值建议设为
@media (max-height: 450px)，也可叠加and (orientation: landscape)提升精度
最后检查三件事，Safari 下菜单高度才真正稳
很多“修好了又崩”的情况，其实卡在这三个容易被跳过的点上：
- 确认菜单容器没有被父级设了
pointer-events: none或transform导致渲染层异常 - 如果菜单用了 Flex 布局，内层子项含
<img>，务必设height: auto或显式宽高比容器，否则 Safari 无法估算最小高度 - 禁用
overflow: hidden配合flex: 1——某些 Safari 版本会因此抑制align-items: stretch，导致高度塌陷
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
