有没有过这种崩溃时刻？点击一个受权限管控的hover按钮，按钮失焦后唤起Modal，结果弹窗刚弹出来，页面突然毫无征兆地滚到某个角落——可能是表格里某一行，可能是表单深处的输入框，甚至是个完全无关的DOM节点。更气人的是，这个问题时有时无，排查起来像碰运气。我今天遇到这个情况，翻了一堆资料才搞懂，这根本不是玄学，而是浏览器默认行为和前端框架的“乌龙碰撞”。

相信不少前端开发者都踩过类似的坑：点击按钮弹出Modal或Dropdown，弹窗出现瞬间页面突然“跑偏”，滚动到一个完全意想不到的位置。这个行为毫无规律，有时出现有时消失，定位起来特别棘手。

问题的本质，其实是focus()方法的“副作用”在搞鬼。按照WAI-ARIA无障碍规范，弹窗打开时应该自动将焦点移到弹窗容器上，方便屏幕阅读器和键盘用户感知交互上下文，这是Ant Design做焦点管理的初衷。但浏览器执行focus()时有个默认行为：如果目标元素不在可视区域内，会自动滚动页面把它“拉”到视野里——这就是页面乱滚的直接原因。

场景高度相似：Modal嵌套Table时，页面滚到表格某一行；弹窗里有长表单，焦点落在靠后的输入框，页面跟着滚到底部；Dropdown弹出时，页面滚到触发元素附近带tabindex的节点。谁能想到，莫名其妙的滚动居然和无障碍焦点管理有关？

Ant Design官方后来给出了修复方案：调用focus()时加上preventScroll: true参数。这是原生DOM API提供的能力，意思是“让元素获得焦点，但别滚动页面”。既保留了无障碍的焦点管理，又避免了页面滚动被意外打断，算是两全其美。

不过如果你还在使用Ant Design 3.x或更早版本，可能会发现这个方案不生效。一是因为preventScroll是后续版本才引入的，旧版本还是普通的focus()调用；二是部分旧浏览器对这个参数支持不完整；还有些嵌套组件或自定义渲染的场景，焦点管理的代码路径没被完全覆盖。

这种情况下，社区里流传的几个Hack手段可以应急：

第一种是移除不必要的tabindex。既然带tabindex的元素会被视为“可聚焦”对象，那把不需要参与焦点管理的元素上的tabindex属性删掉，就能从源头上减少触发滚动的可能。比如把<div tabindex="-1" class="mask">这类非必要的tabindex去掉。

第二种是手动控制焦点。在弹窗打开后，主动把焦点设置到你期望的位置，比如弹窗的确认按钮或标题栏。用React的话，可以在useEffect里监听弹窗可见状态，找到目标元素后调用focus({ preventScroll: true })，避免浏览器“自作主张”。

第三种则简单粗暴：弹窗打开前先记录当前滚动位置，打开后立刻将页面滚回去。比如const scrollTop = window.scrollY，执行弹窗打开操作后再window.scrollTo(0, scrollTop)，虽然有点“硬来”，但某些场景下特别有效。

最后划个重点：

• 根本原因：focus()触发浏览器默认的“滚动到可视区域”行为
• 设计初衷：为了无障碍访问，弹窗打开时需要自动聚焦
• 官方方案：使用focus({ preventScroll: true })
• 旧版本应对：3.x及以下可能需要手动Hack
• 排查思路：检查弹窗内带tabindex的元素和焦点管理逻辑
• 
  

下次再遇到Modal打开页面乱滚的问题，别再“玄学排查”了——从focus()和tabindex入手，大概率就能找到答案。