focus({preventScroll: true}) 失效主因是元素不可聚焦或未就绪：如 display: none、visibility: hidden、父容器裁剪、DOM 未渲染完成；Safari 不支持该参数，需运行时检测 FocusOptions.prototype.preventScroll；且它仅阻止聚焦瞬间滚动，不干预后续输入导致的自动滚动。
focus({preventScroll: true}) 在编辑器中为何常失效
直接调用 element.focus({preventScroll: true}) 后页面仍滚动，大概率不是代码写错，而是元素本身不满足聚焦前提。编辑器里常见的可聚焦目标（如 contenteditable 元素、textarea 或自定义 div[tabindex="0"]）若处于以下任一状态，preventScroll 就不会生效：display: none、visibility: hidden、被父容器 overflow: hidden 裁剪且不在视口内。更隐蔽的是：某些编辑器框架（如 Slate、TipTap）会在聚焦前异步 patch DOM，导致调用时元素尚未完成渲染。
动态插入的编辑器容器怎么安全聚焦
很多富文本编辑器通过 JS 动态挂载内容区域（比如初始化后才插入 div[contenteditable="true"]），此时立即 .focus() 会静默失败。不能依赖 setTimeout(() => el.focus(), 0) —— 它不保证渲染完成。
- 用
requestAnimationFrame延迟一次绘制周期：editorContainer.insertAdjacentHTML('beforeend', '<div contenteditable="true" tabindex="0"></div>');<br>const editable = editorContainer.querySelector('[contenteditable]');<br>requestAnimationFrame(() => editable.focus({preventScroll: true})); - 若编辑器基于 React/Vue，确保在
useEffect/onMounted的“DOM 已挂载”回调中执行，而非组件 setup 阶段 - 对 Shadow DOM 内的编辑器，必须先确认
shadowRoot可访问，再查子节点
用户键入时又自动滚动？preventScroll 只管初次聚焦
preventScroll 仅作用于 focus() 调用那一刻，它无法阻止后续用户输入触发的浏览器默认滚动（比如在长文档底部编辑时，按回车新增段落，光标移出视口，浏览器会自动滚动）。这是常见误解。
- 真正要拦截输入过程中的滚动，得监听
keydown事件并e.preventDefault()，再手动更新内容（适用于高度可控的 textarea 场景） - 对
contenteditable，该方案不可行 —— 它的输入逻辑太复杂，强行拦截会破坏格式、撤销栈和 IME 支持 - 更务实的做法：聚焦后主动调用
element.scrollIntoView({ block: 'nearest', inline: 'start' })，用nearest避免强制滚动到顶部，比放任浏览器默认行为更可控
兼容 Safari 的 preventScroll 写法必须加检测
Safari 目前（截至 2026 年 6 月）仍不支持 focus({preventScroll: true})，传入对象参数会静默忽略，元素照常获得焦点但页面依然滚动。不能靠 UA 判断，得运行时检测：
立即学习“前端免费学习笔记（深入）”；
if ('preventScroll' in FocusOptions.prototype) {<br> editable.focus({preventScroll: true});<br>} else {<br> editable.focus();<br>}
注意：这个检测必须在调用前执行，不能只在首次加载时缓存结果 —— 某些编辑器会复用同一 DOM 节点切换模式（如源码/预览），每次聚焦都需重新判断。
真正难处理的不是聚焦本身，而是编辑器内容动态变化后光标位置与滚动状态的耦合。preventScroll 只是起点，后续是否需要 scrollIntoView、何时重置 focus 状态、如何与 undo/redo 同步，这些细节才决定最终体验是否“稳”。
