根本原因是 ios safari 和部分安卓 webview 中:focus-within 响应输入框聚焦时强制弹出软键盘，导致视口压缩、布局突变，而:focus-within 样式已提前生效，造成视觉错位。
移动端 :focus-within 触发时键盘遮挡表单控件的根本原因
不是 :focus-within 本身有问题，而是它在 iOS Safari 和部分安卓 WebView 中会响应 input 或 textarea 获得焦点——此时系统强制弹出软键盘，视口被压缩、position: fixed 或底部按钮可能被顶出可视区，而 :focus-within 的父容器样式（比如高亮边框、展开提示）又恰好依赖于这个“被遮挡的布局状态”。关键在于：浏览器在键盘弹出前不触发重排，但 :focus-within 已生效，样式已应用，随后布局突变导致视觉错位。
用 resize 事件 + window.visualViewport 检测键盘状态
iOS 16.4+ 和较新安卓 Chrome 支持 window.visualViewport，它是判断软键盘是否弹出最可靠的依据。配合 resize 事件可实时感知视口高度变化，从而延迟或修正 :focus-within 相关行为。
实操建议：
- 监听
visualViewport?.addEventListener('resize', handler)，而非仅靠focus/blur - 当
visualViewport.height显著小于window.innerHeight（例如差值 > 150px），视为键盘弹出中 - 此时可临时移除父容器上的
focus-within-active类，或用transform: translateY()微调提示区域位置 - 避免在
resize中直接操作 DOM 样式，改用requestAnimationFrame批量更新
:focus-within 在表单容器上慎用 scrollIntoView 或 focus()
很多方案试图在 :focus-within 生效后自动 scrollIntoView({ block: 'nearest' })，但在移动端极易引发二次滚动抖动或焦点丢失——尤其当输入框位于底部、键盘弹出后视口重算尚未完成时，scrollIntoView 可能滚动到错误位置，甚至把输入框滚到键盘下方。
更稳妥的做法：
- 完全放弃在
:focus-withinCSS 规则中隐式触发滚动；滚动逻辑必须由 JS 控制，且只在visualViewport.height稳定后再执行 - 对
input[type="text"]、textarea单独绑定focus事件，在事件回调中调用el.scrollIntoView({ behavior: 'smooth', block: 'center' }) - 加
setTimeout延迟 100ms 再滚动，避开 iOS 键盘动画起始帧 - 安卓 WebView 中若
scrollIntoView失效，可 fallback 到el.getBoundingClientRect().top + window.scrollY - 80手动计算 scrollTop
兼容性兜底：iOS 15.4 以下无法读取 visualViewport 怎么办
老版 iOS Safari 不暴露 visualViewport，也无法通过 window.innerHeight 变化可靠判断键盘——因为页面缩放、地址栏收起也会改变高度。这时只能依赖启发式检测。
可行策略：
- 监听
focusin事件，对所有可聚焦元素记录el.tagName和el.type，当目标是INPUT或TEXTAREA时，假设键盘即将弹出 - 结合
window.matchMedia('(pointer: coarse)').matches判断是否为触屏设备，进一步提高置信度 - 设置一个 300ms 的防抖计时器，若期间无
blur事件，则认为键盘已弹出，启用遮挡规避逻辑（如提升提示层 z-index、临时设body { position: fixed }） - 注意：不要在
focusin中立即修改body定位，这会导致页面跳动；应先加 class，再用 CSS transition 平滑过渡
真正难处理的不是 :focus-within 的语法，而是它和移动端输入法生命周期之间的时序裂缝。视觉反馈、滚动、定位三者必须在同一个“键盘就绪”状态下协同，否则用户看到的就是闪烁、错位、或输入框被盖住——这些都不是样式写错了，是时机没卡准。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
