fixed元素锚定视觉视口，软键盘压缩该视口但不触发重排，导致定位错位；resize事件延迟或缺失、env(keyboard-inset-bottom)兼容性差，稳定方案需组合visualviewport监听与fallback机制。
不是你 position: fixed 写错了，而是浏览器把 fixed 元素锚定在「视觉视口（visual viewport）」上，而软键盘弹出会压缩这个视口——但 fixed 的计算值不会重算，结果元素就飘在键盘上方空白处。
fixed 锚定的是 visual viewport，不是 layout viewport
iOS 和多数安卓 WebView 把软键盘视为“覆盖层”，只缩 visual viewport.height，却不触发 layout viewport 重排。bottom: 0、100vh、甚至 @media (max-height: ...) 都基于初始或 layout 视口，根本感知不到 visual viewport 的动态压缩。
-
window.innerHeight在键盘弹出后会变小，但 fixed 元素的定位坐标仍按旧值渲染 -
document.documentElement.clientHeight通常不变，它反映的是 layout viewport，和用户实际看到的区域脱节 - 哪怕加了
viewport-fit=cover，也只影响安全区，不改变 fixed 的锚点逻辑
resize 事件不可靠，focusin 又太早
你以为监听 resize 就能捕获键盘弹出？现实是：
- iOS Safari 中
resize延迟严重，常在键盘完全展开后 300–500ms 才触发，且可能连发多次 - 安卓部分 WebView 根本不触发
resize，或者只在键盘收起时才触发一次 -
focusin触发时键盘还没弹出来，getBoundingClientRect()返回的是旧坐标，直接读会错位
env(keyboard-inset-bottom) 不是万能解，仅限 iOS 16.4+
这个 CSS 环境变量确实干净，但它只在 iOS Safari 16.4+ 上生效，安卓全系不支持，旧版 iOS 会忽略整条规则甚至导致解析失败。
- 必须用
@supports (bottom: env(keyboard-inset-bottom))包裹，否则降级失效 - 不能和
svh混用，比如bottom: calc(0px + 100svh)是无效写法 - 即使启用了，iOS 键盘收起后
window.innerHeight也不立即恢复，需手动判断阈值并清理状态
真正稳定的方案永远是组合：用 visualViewport.height 做主监听（现代浏览器），fallback 到 focusin/blur + setTimeout(() => {}, 0) 动态切 position: absolute，再用 padding-bottom 或 margin-bottom 做兜底。任何只改一个 CSS 属性或只绑一个事件的方案，在真实机型上都大概率穿帮。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
