resize事件在ios和多数安卓webview中不可靠，无法准确检测键盘弹出；应结合focusin与resize双信号，利用visualviewport.height和getboundingclientrect()动态计算底部间距并防抖处理。
只监听 resize 事件在 iOS 和多数安卓 WebView 中基本不可靠，不能作为键盘弹出检测的主逻辑——它既不保证触发，也不保证时机准确，单独使用会导致底部按钮被顶出视口、输入框被遮挡。
为什么 resize 在键盘弹出时经常不触发或延迟
iOS Safari（尤其是 15.4+）根本不会为软键盘弹出触发 resize；Android 行为分裂：Chrome 可能延迟 300ms 才发一次，而某些厂商 WebView 压根不发。这不是 bug，是浏览器把键盘当作「覆盖层」而非「视口重绘」的设计选择。更糟的是，window.innerHeight 在键盘刚弹出时可能不变、突变、或抖动多次，仅靠它和 resize 做差值判断，漏判率高、误判频繁。
focusin + resize 双信号联动才是可行起点
单靠任一信号都稳不住，但组合起来能覆盖绝大多数真实交互场景：
- 监听所有
input和textarea的focusin（不是focus，冒泡更可靠），触发时立即缓存当前window.innerHeight和visualViewport?.height - 同时绑定
window.addEventListener('resize', handler)，并在 handler 中检查：visualViewport.height比初始值小 >150px，或window.innerHeight突降且 200ms 内未恢复 - 用
setTimeout+clearTimeout做简单防抖，只在高度“稳定”后执行定位切换，避免反复 toggleposition - 别在
focusin回调里直接改样式——加setTimeout(() => {}, 0)或requestAnimationFrame，确保 DOM 渲染完成后再读取getBoundingClientRect()
切换 fixed 为 absolute 时 bottom 怎么算才准
不能硬写 bottom: 0，也不能只靠 innerHeight 差值估算：
- 先获取焦点元素位置：
const rect = input.getBoundingClientRect() - 计算它距视口底边的真实距离：
const bottomSpace = window.innerHeight - rect.bottom - 把这个值设给你的按钮：
el.style.bottom = `${bottomSpace}px` - 注意：安卓部分 WebView 中
getBoundingClientRect()在键盘刚弹出时会返回错误值，所以必须等resize或visualViewport.resize触发后再读一次
键盘收起后恢复 fixed 的时机很关键
别依赖 blur 或 focusout——用户可能点键盘“收起”按钮，而 input 仍保持焦点；也可能切到其他输入框，导致状态混乱：
- 优先监听
visualViewport.addEventListener('resize', )，当height恢复到接近初始值（误差 - 无
visualViewport时，退回到监听resize，并加 300ms 延迟，确认高度不再抖动 - 恢复前务必清除所有内联
style.bottom和style.position，否则残留样式会干扰后续定位
真正容易被忽略的点在于：几乎所有方案都卡在「焦点状态是否真实」「坐标系是否被 transform/overflow 扰动」「iOS 键盘收起后 innerHeight 恢复延迟」这三处——它们不会报错，但会让计算结果偏移几十像素，最终表现为按钮悬在半空或一闪而过。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
