focus({preventscroll: true})常不生效是因为元素未准备好聚焦，如隐藏、未渲染、在shadow dom内或safari不支持该参数；需用requestanimationframe、useeffect、onmounted等确保时机，并运行时检测支持性。
focus({preventScroll: true}) 为什么在编辑器里常不生效
不是参数写错了，而是元素根本没准备好被聚焦。编辑器里常见的 contenteditable 元素或带 tabindex="0" 的容器，若处于以下任一状态，preventScroll 就会静默失效：
-
display: none或visibility: hidden - 父容器设置了
overflow: hidden且该元素不在视口内 - DOM 尚未完成渲染（比如 Slate/TipTap 初始化后才挂载内容区域）
- 在 Shadow DOM 内但未正确访问
shadowRoot
浏览器不会报错，焦点也不会真正获得——preventScroll 前提是聚焦成功，它只管“怎么聚焦”，不管“能不能聚焦”。
动态插入的编辑器内容怎么安全调用 focus({preventScroll: true})
不能靠 setTimeout(() => el.focus(), 0)，它不等渲染，只等 JS 队列空闲。真实有效的时机是浏览器完成一次绘制周期：
- 原生 JS：用
requestAnimationFrame延迟一次，确保样式计算和布局已完成 - React：放在
useEffect里，且依赖项为空数组（即挂载后执行） - Vue：在
onMounted回调中执行，而非setup函数体内部 - Shadow DOM：先确认
el.shadowRoot存在，再查子节点，否则querySelector返回null
示例：
const editable = editorContainer.querySelector('[contenteditable]');<br>requestAnimationFrame(() => editable.focus({preventScroll: true}));
Safari 兼容写法必须检测 preventScroll 支持性
Safari 目前完全不支持 preventScroll 参数，传入对象会静默忽略，元素仍能聚焦，但滚动照常发生。不能靠用户代理判断，得运行时检测：
- 正确检测方式：
'preventScroll' in FocusOptions.prototype - 错误方式：
typeof el.focus === 'function'或检查浏览器版本字符串 - 降级逻辑必须显式写出：
if ('preventScroll' in FocusOptions.prototype) { el.focus({preventScroll: true}); } else { el.focus(); }
注意：这个检测本身在 Safari 中会返回 false，所以分支一定会走到基础 focus()，这是预期行为。
用户开始输入后又自动滚动？preventScroll 不负责这个
preventScroll 只影响 focus() 调用那一刻的滚动行为，对后续任何输入导致的滚动（比如在长文档底部按回车、光标移出视口）完全无感。这是最常被误解的一点。
- 对
textarea：可监听keydown并e.preventDefault()，再手动更新value和光标位置 - 对
contenteditable：不建议拦截keydown，会破坏 IME、撤销栈和格式保留 - 更务实的做法：聚焦后立刻调用
element.scrollIntoView({ block: 'nearest', inline: 'start' })，用nearest避免强制拉到顶部，比放任浏览器默认滚动更可控
真正难处理的从来不是“怎么不让它滚”，而是“什么时候该让它滚、滚多少”。编辑器场景下，preventScroll 只是起点，不是终点。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
