iOS上仅监听resize事件失效，因键盘弹出/收起时resize触发延迟、抖动且innerHeight变化不敏感；应采用focusin+resize双信号联动，结合visualViewport.height与防抖判断键盘状态，并用getBoundingClientRect()动态计算bottom值。
为什么只监听 resize 事件在 iOS 上经常失效
因为 iOS Safari 的 resize 事件不随虚拟键盘弹出/收起稳定触发：它可能延迟 300–500ms 才发出，也可能连续触发多次，甚至在键盘完全展开后才第一次触发。更关键的是，window.innerHeight 在键盘弹出瞬间未必突变——有些版本里它几乎不变，导致你用高度差判断失败。纯靠 resize + innerHeight 对比，在 iOS 上漏判率高、抖动严重。
真正可靠的判断逻辑是 focusin + resize 双信号联动
单靠任一信号都不稳，但组合起来能覆盖绝大多数场景：
- 监听所有
input、textarea的focusin事件，触发时立即记录当前window.innerHeight和visualViewport.height（后者 iOS 15.4+ 支持，更贴近真实可视区） - 同时绑定
resize，并在 handler 中比较：若visualViewport.height比初始值小 > 150px，或window.innerHeight突降且持续 200ms 未恢复，则判定键盘已弹出 - 用
setTimeout+clearTimeout做简单防抖，只在高度“稳定”后执行定位切换，避免反复 toggleposition - 不要在
focusin回调里直接改样式——加setTimeout(() => {}, 0)确保 DOM 渲染完成后再读取getBoundingClientRect()
切换 fixed 为 absolute 时 bottom 怎么算才准
不能硬写 bottom: 0，也不能只靠 innerHeight 差值估算。正确做法是：
- 先获取焦点元素的位置：
const rect = input.getBoundingClientRect() - 计算它距离视口底部的真实距离：
const bottomSpace = window.innerHeight - rect.bottom - 把这个值作为
bottom设置给你的按钮：el.style.bottom = `${bottomSpace}px` - 注意：安卓部分 WebView 中
getBoundingClientRect()在键盘刚弹出时会返回错误值，所以必须等resize或visualViewport.resize触发后再读一次
键盘收起后恢复 fixed 的时机很关键
别依赖 blur 或 focusout——用户可能点键盘“收起”按钮，而 input 仍保持焦点；也可能切到其他输入框，导致状态混乱。稳妥做法是：
- 监听
visualViewport的resize事件（iOS/Chrome 支持），当height恢复到接近初始值（误差 position: fixed - 没有
visualViewport时，退回到监听resize，并加一个 300ms 延迟，确认高度不再抖动 - 恢复前务必清除所有内联
style.bottom和style.position，避免和 CSS 类冲突 - 如果页面有多个输入框共用同一底部栏，需用一个全局变量记录当前是否“键盘活跃”，而不是每个
focusin都单独处理
实际最易被忽略的点是：你写的“恢复 fixed”逻辑，往往在键盘还没完全收起时就执行了，结果按钮闪一下又掉下去。这不是代码错，而是没等系统把视口高度真正还回来。得盯住 visualViewport.height，而不是只看事件。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
