autofocus 本身不触发滚动，但浏览器聚焦时自动滚动元素会引发视口重排、滚动条突显、fixed元素错位及dialog嵌套跳动等问题，根源在于滚动行为触发溢出重计算与布局时机冲突。
autofocus 本身不会触发滚动，但浏览器会在聚焦时自动滚动到该元素——这个行为在某些布局下会引发滚动条突然出现、视口重排、内容错位等连锁反应，本质是滚动 + 溢出计算 + 视口变化三者叠加的结果。
autofocus 触发的自动滚动会暴露 overflow:auto 容器的宽度坍缩
当 autofocus 元素位于 overflow:auto 的父容器内（比如弹窗内容区），浏览器聚焦时会尝试将该元素滚动进可视区。此时若容器宽度未显式固定，且子元素使用百分比或 margin: 0 auto 居中，滚动动作可能触发容器重绘，暴露出滚动条——而滚动条出现瞬间会挤占可用宽度，导致内容向左偏移。
- 根本原因不是 autofocus，而是滚动行为触发了容器的溢出重计算
- 尤其在 Safari 中，
focus()或autofocus后的滚动是同步且不可取消的 - 避免方案：给容器设
overflow-y: scroll（常驻滚动条），或用padding-right预留滚动条空间（如padding-right: 16px） - 不要依赖
width: 100%+margin: 0 auto在可滚动容器中居中——改用display: flex; justify-content: center
fixed 或 sticky 定位元素在 autofocus 滚动后“消失”或错位
如果页面底部有 position: fixed 的提交按钮，而 autofocus 的输入框在顶部，浏览器滚动聚焦时会把整个视口往上推，导致 fixed 元素脱离原始锚点位置——它仍按原 window.innerHeight 定位，但实际可视区域已变小，视觉上就像“被顶走”或“卡在半空”。
- 这不是 CSS 错误，而是 fixed 元素锚定逻辑与滚动行为冲突
- iOS Safari 尤其明显：键盘弹出 + autofocus 滚动 + fixed 元素 = 三重视口扰动
- 解决方案：把 fixed 按钮换成
position: sticky; bottom: 0;，并确保其父容器有明确高度约束 - 或者，在
focusin事件里临时加body { overflow: hidden; }，阻止默认滚动（需失焦后恢复）
多层 dialog 嵌套时 autofocus 滚动目标混乱
当多个 <dialog></dialog> 嵌套或快速切换，首个 dialog 的 autofocus 可能成功，但后续 dialog 的 autofocus 被忽略；而 JS 手动调用 focus() 时，浏览器仍会执行一次自动滚动——但此时滚动目标可能是已关闭的旧 dialog，或尚未完全渲染的新 dialog，造成页面跳动甚至空白滚动。
- 滚动目标错误的根本原因是：focus() 发生时，DOM 尚未完成 layout，
getBoundingClientRect()返回无效值 - 不要在
showModal()后立即 focus()，改用dialog.addEventListener('focusin', () => input.focus(), { once: true }) - 务必检查
input是否满足可聚焦条件：disabled为 false、tabindex不为 -1、父级无inert - 对 iOS Safari，所有 focus() 必须发生在用户手势同步上下文中——哪怕包装一层
requestAnimationFrame都不够，得确保是 click/tap 直接触发
真正麻烦的不是 autofocus 本身，而是它像一根导火索，把布局脆弱点（滚动条宽度、fixed 锚点、dialog 渲染时机、iOS 视口重算）全引燃了。修复时别只盯着 HTML 属性，得顺着滚动行为往 DOM 生命周期和视口状态里查。
