position: fixed在移动端输入法弹出时移位，根本原因是浏览器未将键盘视为视口变化：iOS冻结layout viewport却上推页面，Android压缩window.innerHeight却不触发fixed重算；监听resize不可靠，应以focusin/blur为入口，用relative+absolute模拟fixed，并约束容器高度、同步状态、适配安全区。
移动端输入法弹出时 position: fixed 元素移位，不是样式写错了，而是浏览器根本没把键盘当作视口变化来响应——iOS 冻结 layout viewport 高度却上推页面，Android 压缩 window.innerHeight 但不通知 fixed 重算位置。硬调 bottom: 0 或 100vh 没用，得换布局结构绕过去。
为什么不能只靠监听 resize
window.onresize 在 iOS 上大概率不触发，安卓行为分裂：Chrome 可能延迟 300ms 才发事件，而键盘弹出后 UI 已错乱。focus/blur 才是唯一稳定、及时、可预测的入口点——用户点进 input 的瞬间，你就该开始准备。
- 别把
resize当主逻辑，它只能辅助处理横竖屏切换 - 在
resize回调里直接改style.top会强制同步重排，滚动卡顿明显 - 真机测试时，微信 WebView 中
resize触发率低于 20%
用 relative + absolute 替代 fixed 的关键约束
核心不是“换个定位方式”，而是让容器高度可控、状态可同步。fixed 失效是因为它锚定在不可靠的视口上；absolute 锚定在 relative 祖先上，只要这个祖先不随键盘乱跳，就能稳住。
- 根容器必须设
position: relative和height: 100vh，同时加overflow: hidden或touch-action: manipulation禁止 body 滚动 - 底部区域用
position: absolute; bottom: 0; width: 100%，内部用display: flex，不依赖文档流 - 监听
focusin到input或textarea时，检查window.innerHeight是否比初始值小 >200px；若是，给底部区加keyboard-active类，切为position: static并设margin-top: auto -
blur后需setTimeout(() => { window.scrollTo(0, 0) }, 100)强制恢复滚动锚点，尤其 iOS 微信中收起键盘后常卡在高位
relative 容器高度失真的真实原因与解法
100vh 在键盘弹出时仍等于物理屏幕高度，不是可用视口高度，所以不能直接靠它撑开容器。失真根源是视口坐标系和渲染坐标系脱节，尤其在高 DPR 设备上。
- 必须配
<meta name="viewport" content="width=device-width, initial-scale=1.0, viewport-fit=cover">，启用安全区适配 - 用
env(safe-area-inset-bottom)动态设容器padding-bottom，避免底部被遮挡 - 老浏览器降级方案：JS 记录初始
screen.height，键盘弹出时估算高度差，再设bottom: calc(0px + [键盘高度]px) - 注意：若 absolute 元素父级有
transform或overflow: hidden，getBoundingClientRect()可能返回错误坐标，务必先确认document.activeElement === inputEl
什么时候该放弃模拟，直接嵌入输入框
如果底部按钮语义上就是输入操作的一部分（比如聊天页的「发送」、搜索页的「语音」），最稳方案是彻底脱离 fixed/absolute 思维：把按钮作为 input 的兄弟节点，用 display: flex 或 grid 布局内联，由父容器统一控制位置和高度。
这种结构天然规避所有键盘重绘问题，也不需要监听任何事件或计算偏移量——但它要求 DOM 结构配合业务语义，不是所有场景都适用。真正棘手的是混合场景：viewport 正确、无 transform 干扰、仍错位——这时大概率是 WebKit 的合成层 bug，得靠 translateZ(0) + backface-visibility: hidden 强制 GPU 加速，而非继续调定位。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
