fixed元素在键盘弹出时“飘起”是因为iOS和安卓WebView不将软键盘视为视口变化，fixed仍按原始window.innerHeight计算位置；应使用visualViewport API监听真实可视高度，或用absolute模拟fixed，或直接将按钮嵌入输入框父容器。
为什么 fixed 在键盘弹出时会“飘”起来
这不是你 position: fixed 写错了，而是 iOS 和多数安卓 WebView 根本不把软键盘当作「视口变化」来响应。它们压缩的是 visualViewport.height，但 fixed 元素仍按原始 window.innerHeight 计算位置——结果按钮就浮在键盘上方空白处，甚至被顶出屏幕。用 bottom: 0 或 100vh 都无效，因为这些值不会随键盘动态更新。
用 visualViewport API 监听真实可视高度（现代浏览器首选）
这是目前最准、最轻量的方案，能直接拿到用户真正看到的高度，不依赖抖动的 resize 或不可靠的 window.innerHeight：
- 页面加载时先存基准高度：
const baseHeight = visualViewport.height - 监听变化：
visualViewport.addEventListener('resize', () => { const kbHeight = baseHeight - visualViewport.height; }) - 用
transform: translateY(${kbHeight}px)调整按钮位置，比改bottom更少触发重排 - iOS Safari 15.4+、Chrome 61+ 支持；老版本必须降级，不能只靠它
用 absolute 模拟 fixed（兼容性最广）
核心不是换定位方式，而是让祖先容器高度可控。只要根容器稳定，absolute 就不会被键盘拖走：
- 根容器（如
#app）设position: relative和min-height: 100vh，并加overflow: hidden禁用 body 滚动 - 底部区域用
position: absolute; bottom: 0; width: 100%，内部用display: flex布局按钮 - 监听
focusin到input或textarea，用setTimeout(() => { }, 0)确保 DOM 更新后再读getBoundingClientRect().bottom -
blur后必须立刻恢复position: fixed和bottom: 0，否则滚动时元素会消失或错位
什么时候该放弃模拟，直接嵌入输入框
如果底部按钮语义上就是输入操作的一部分（比如聊天页的「发送」、搜索页的「语音」），最稳方案是彻底脱离 fixed/absolute 思维：
立即学习“前端免费学习笔记（深入）”；
- 把按钮作为
input的兄弟节点，放在同一个position: relative容器里 - 用
display: flex; justify-content: space-between或align-items: center对齐 - 避免任何依赖全局视口的定位逻辑，从根源绕过键盘干扰
所有方案都卡在三个地方：iOS 键盘收起后 window.innerHeight 不立即恢复、focusin 触发早于键盘完全展开、Safari 对 window.scrollTo() 有节流策略——这意味着延迟、阈值判断和手动锚点恢复不是可选项，是必做动作。
