根本原因是fixed定位在android和ios对viewport解释不一致：android中window.innerheight随软键盘缩小，ios基本不变，导致fixed元素卡在键盘下；sticky更合适因其不脱离文档流、能响应视口变化，需父容器设height:100vh和overflow-y:auto才能触发。
移动端 fixed 输入框被软键盘遮挡的根本原因
不是 CSS 写错了，而是 fixed 定位在不同平台对视口（viewport）的解释不一致：window.innerHeight 在 Android WebView 中会随软键盘弹出而缩小，而 iOS Safari 的 window.innerHeight 基本不变。fixed 元素始终按“原始视口高度”定位，键盘一弹，它就卡在键盘底下——尤其当输入框本身也用 position: fixed 放在底部时，问题最明显。
为什么 sticky 比 fixed 更适合输入框容器
position: sticky 不脱离文档流，能响应滚动和视口变化，且天然规避了键盘导致的定位失效问题。它只在父容器可滚动、且元素到达临界点时才“粘住”，不会被键盘强行拖离上下文。
- 必须给父容器设明确高度（如
height: 100vh）和overflow-y: auto，否则 sticky 不触发 - 输入框容器用
position: sticky; bottom: 0;，同时加z-index: 1000防止被内容穿透 - iOS 15.4+ 和 Chrome 90+ 均支持；旧版可降级为 fixed + JS 补位，无需 polyfill
env(keyboard-inset-bottom) 怎么用才不白写
iOS 16.4+ 原生支持 env(keyboard-inset-bottom)，但它只在 Safari 有效，安卓完全不识别。直接写 bottom: env(keyboard-inset-bottom); 而不加降级，等于在安卓上留了个 0px 的坑。
- 正确写法是搭配
@supports判断：@supports (bottom: env(keyboard-inset-bottom)) { .input-wrapper { bottom: env(keyboard-inset-bottom); } } @supports not (bottom: env(keyboard-inset-bottom)) { .input-wrapper { bottom: 0; } } - 不能只依赖这个变量做全部适配——它只返回键盘高度，不解决键盘弹出时页面滚动错位问题
- 若同时用了
safe-area-inset-bottom，需叠加：bottom: calc(env(keyboard-inset-bottom, 0px) + env(safe-area-inset-bottom, 0px));
监听 focus/blur 动态调整位置的实操要点
纯 CSS 方案总有盲区，JS 补位仍是兜底关键。但别一上来就 scrollIntoView 或 scrollTop，容易在 iOS 上触发两次滚动或失效。
- 优先监听
focusin和focusout，而非focus/blur——前者冒泡，能捕获子元素聚焦 - 用
visualViewport?.height变化比window.innerHeight更可靠（iOS 15.4+ 支持），下降超 150px 就判定键盘弹出 - 动态改样式时，避免直接操作
style.bottom，推荐切换 class：.input-wrapper.keyboard-active { position: absolute; bottom: env(keyboard-inset-bottom, 200px); } - 失焦后别立刻恢复 fixed——加个
setTimeout(..., 100)等键盘动画收完再切，否则 iOS 会闪一下
真正难的不是写对某一行 CSS，而是得同时兼顾视口变化、层叠上下文、安全区、键盘状态四个维度。一个 transform: translateZ(0) 加在父容器上，就可能让整个 fixed 输入框在 iOS 上瞬间消失——这种细节，调试时根本不会报错，只会默默出问题。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
