根本原因是ios safari和部分安卓webview中:focus-within响应输入框聚焦时强制弹出软键盘，导致视口压缩、布局突变，而:focus-within样式已提前生效，造成视觉错位；应优先监听visualviewport.resize事件，当height显著减小（>150px）时动态调整样式或位置，并用requestanimationframe批量更新，避免直接操作dom。
移动端:focus-within触发键盘弹出时布局错位怎么防
根本问题不是:focus-within写错了，而是它在 iOS Safari 和部分安卓 WebView 中会响应 input 或 textarea 聚焦——此时系统强制弹出软键盘，视口高度突变，而 :focus-within 样式已提前生效，导致高亮区域被顶出可视区或遮挡输入框。
关键在于：浏览器不等键盘动画完成就应用 CSS，且不触发重排，视觉状态和实际布局脱节。
- 优先用
window.visualViewport?.addEventListener('resize', handler)替代focus/blur事件监听，它是判断键盘是否弹出最可靠的依据 - 当
visualViewport.height比window.innerHeight小超过 150px，视为键盘弹出中，此时可临时移除父容器上的focus-within-active类，或用transform: translateY()微调提示区域位置 - 避免在
resize回调里直接改 DOM 样式，改用requestAnimationFrame批量更新，防止卡顿
:focus-within在表单容器上为什么滚动会翻车
很多方案在 :focus-within 规则里隐式触发 scrollIntoView，但在移动端极易滚动错位甚至把输入框滚到键盘下方——尤其当输入框位于页面底部、键盘刚弹出时视口尚未稳定。
更稳妥的做法是完全放弃 CSS 隐式滚动，改由 JS 控制，且只在键盘状态稳定后执行。
- 对
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 Safari（15.4 以下）不支持 visualViewport 怎么兜底
iOS 15.4 以下无法读取 window.visualViewport，也无法靠 window.innerHeight 变化可靠判断键盘状态——这是兼容性硬伤，不能靠“差不多就行”糊弄。
实操上必须降级为行为检测+超时判断，而非样式 fallback。
- 监听
focus事件后，立即记录当前window.innerHeight - 启动
setTimeout（300ms），期间若innerHeight显著变小（如 - 配合
blur事件清理定时器，防止内存泄漏 - 对
input加data-keyboard-aware="true"标记，便于统一管理降级逻辑
React/Vue 组件里:focus-within失效的典型结构坑
不是浏览器不支持，而是框架封装层切断了焦点链——比如 <myinput></myinput> 渲染后内部 <input> 没透传 tabIndex，或被 tabindex="-1" 拦住，:focus-within 就查不到活跃后代。
检查点非常具体：打开 DevTools，手动点击输入框，看焦点是否真落在原生 <input> 上，而不是外层 <div>。<ul>
<li>自定义组件必须显式透传 <code>tabIndex 属性，并确保 ref 正确转发到原生 <input>
<input> 外层包裹带 pointer-events: none 或 visibility: hidden 的 <div>，这会阻断焦点归属判定<li>Vue 用户注意：<code>v-model 不影响聚焦行为，但若用 contenteditable + <div> 模拟输入框，必须手动加 <code>tabindex="0" 并监听 focusin真正难的不是写对一行 :focus-within，而是它在移动端触发时，你得同时应付键盘、视口、焦点链、框架封装四层干扰。任何一个环节松动，高亮就变成错位，滚动就变成抖动。
