100vh在移动端“跳动”是因为Safari和部分安卓WebView的视口高度随地址栏收起/展开动态变化，而DOM未同步重排；postcss-px-to-viewport无法解决，因其仅做编译时px转vw/vh，不干预运行时vh行为。
为什么 100vh 在移动端会“跳动”
因为 Safari 和部分安卓 WebView 的视口高度会随地址栏收起/展开动态变化，100vh 跟着变，但页面 DOM 高度没同步重排，导致视觉上“突然缩一下”或“内容被截”。这不是 CSS 写错了，是浏览器对 vh 的实现机制本身有歧义：它按初始视口算，还是按当前可视区域算？各端不统一。
postcss-px-to-viewport 能不能直接解决这个问题
不能。这个插件只做编译时单位转换，把 height: 100px 变成 height: 26.66667vw 这类静态映射，它不干预运行时的 vh 行为。如果你写的是 height: 100vh，插件默认不会碰它——因为 vh 已经是视口单位，不属于它的转换目标（默认只转 px）。
常见误操作包括：
- 在配置里把
propList设成['*']，以为能强制转vh，其实无效 - 把
viewportUnit: 'vh'当成“让所有高度用 vh”，但它只影响 px → vh 的转换逻辑，不改已有 vh 值 - 开启
mediaQuery: true后，在媒体查询里写了height: 100vh，结果发现跳动更明显——因为媒体查询触发时机和视口变化不同步
真正有效的绕过方案：用 vw 模拟固定视口高度
核心思路：放弃依赖 vh，改用 vmin 或基于设计稿宽度推算“伪固定高度”。比如设计稿宽 375px、高 667px，那么 100% 视口高度 ≈ 667 / 375 * 100vw ≈ 177.86667vw。这个值在编译时就固化下来，不随地址栏变化抖动。
立即学习“前端免费学习笔记（深入）”；
实操建议：
- 在 PostCSS 配置中设
viewportWidth: 375，viewportUnit: 'vw' - 把需要“撑满屏幕”的容器高度写成
height: 667px（按设计稿数值），插件会自动转成height: 177.86667vw - 如果要兼容横屏，用
vmin更稳：height: 667px→ 手动配viewportUnit: 'vmin'，但注意此时需同步调整viewportHeight（插件不原生支持，得 fork 或换postcss-px2vp） - 关键元素（如首页全屏 banner）避免直接写
100vh，宁可多一层 wrapper + JS 动态 setStyle，也比纯 CSS 跳动强
必须手动补位的两个边界场景
vh 跳动最顽固的两个地方，PostCSS 插件完全无能为力，必须代码层兜底：
-
iOS Safari 地址栏收起后首屏留白：监听
resize事件，检测window.innerHeight变化，再用document.documentElement.style.setProperty('--vh', ${vh}px)注入 CSS 变量，样式里用height: var(--vh) -
fixed 定位 + bottom: 0 的弹窗贴底失效：不要依赖
100vh - height计算，改用calc(100% - env(safe-area-inset-bottom))+padding-bottom组合，且确保父容器height: 100%层层透传
PostCSS 处理的是构建时的静态映射，而视口高度抖动是运行时的布局重排问题。越想靠一个插件一劳永逸，越容易在真机上栽跟头。
