100vh在移动端出问题是因为它基于固定布局视口静态计算，不随地址栏收起、键盘弹出或横竖屏切换动态更新，导致内容截断、留白或跳动；应优先使用min-height: 100dvh并用@supports兜底，配合JS动态--vh变量兼容旧环境。
为什么直接用 height: 100vh 会出问题
因为 100vh 指的是视口高度（window.innerHeight），而它在移动端是**动态变化的**：Safari 滚动时收起地址栏，innerHeight 突然变大；Chrome Android 底部导航栏展开时又压窄视口。结果就是长图被截断、留白、或底部内容突然跳上来。
更麻烦的是，横屏触发 orientationchange 时，vh 值不会自动按新方向重算——你得手动监听并重设，但用户滚动+横竖屏+弹窗等组合操作会让逻辑失控。
- 别用
height: 100vh做长图容器主高 - 避免依赖
max-height: 100vh做裁剪，它和 overflow 配合容易导致 iOS 上 touch 事件穿透或卡顿 - 真要撑满可视区，优先用
min-height: 100dvh（注意兼容性）
用 aspect-ratio + object-fit 控制图片本身
长图页核心是「图」，不是「容器」。现代方案应把适配逻辑下沉到 <img> 或背景图层，而不是靠 JS 算高度再塞进 div。
假设设计稿给的是 750×1334 的竖版长图（常见活动页尺寸），你可以：
立即学习“前端免费学习笔记（深入）”；
- 给
<img>加width: 100%; aspect-ratio: 750 / 1334; object-fit: cover;，让浏览器自动按比例缩放并裁切 - 对需要完整展示的长图（如步骤引导图），改用
object-fit: contain，并配合padding-bottom占位防抖动 - 安卓 WebView 低版本不支持
aspect-ratio？补一句height: 0; padding-bottom: calc(1334 / 750 * 100%);
这样无论 iPhone 15 Pro（430px 宽）还是 Galaxy S24（360px 宽），图片宽始终 100%，高按比例自适应，不拉伸不变形。
rem 动态基准必须绑定设备宽度，不能靠 JS 读 window.innerHeight
很多团队还在用 JS 监听 resize 算 html.font-size，但错误地拿 innerHeight 当依据——这会导致横屏时字体突变、按钮错位、甚至触控热区偏移。
正确做法是只依赖宽度：
- 初始化时取
document.documentElement.clientWidth（稳定，不受地址栏影响） - 断点只用
@media (max-width: 375px)、(min-width: 376px) and (max-width: 414px)这类宽度组合 - font-size 公式固定为
100 * (clientWidth / 375) + 'px'（以 iPhone SE 宽度 375px 为基准） - 长图中文字大小统一用
rem，比如标题1.6rem，正文0.88rem，它们会随屏幕宽度线性缩放
iOS Safari 中长图滚动卡顿与 will-change 的误用
长图页常加 overflow-y: scroll 和 -webkit-overflow-scrolling: touch，但 iOS 上一旦给容器设了 will-change: transform 或 opacity，就可能触发合成层爆炸，内存飙升、滚动掉帧。
真实调试中发现：只要长图容器有 transform: translateZ(0) 或 will-change: transform，哪怕只是 hover 状态，iOS 17+ 就会频繁重绘整个长图区域。
- 禁用所有对长图容器的
will-change声明 - 滚动优化交给
contain: strict（仅限现代 iOS）或删掉冗余的transform - 如果必须做入场动画，用
animation+opacity，别用transform移动整张图
最易被忽略的一点：长图页的「首屏判断」不能只看 getBoundingClientRect().top，iOS Safari 在地址栏隐藏后会重排布局，导致计算失效——要用 IntersectionObserver + rootMargin 扩展容错范围。
