不能。ResizeObserver仅监听元素content-box尺寸变化，无法感知视口（可见内容区域）变化，后者由容器尺寸、滚动位置、overflow及滚动偏移共同决定。
ResizeObserver 能不能直接监听编辑器容器的视口变化
不能。ResizeObserver 本身不提供“视口”概念，它只监听目标元素 contentRect（即 content-box）的宽高变化。所谓“编辑器视口”，实际是用户可见内容区域——它由容器尺寸、滚动位置、scrollTop/scrollLeft、以及是否启用 overflow: auto 共同决定。ResizeObserver 只能告诉你容器变没变大变小，不能告诉你当前看到的是哪一段内容。
为什么只 observe 编辑器容器还不够
常见错误是只监听 div#editor-container，然后在回调里无差别重置 scrollTop = 0 或强行 scrollIntoView()——这会导致用户正在编辑的段落突然跳走。真正需要响应的不是“容器尺寸变了”，而是“尺寸变化后，原视口顶部/底部是否已超出可滚动范围”。
- 容器宽度缩小时，可能触发换行 → 内容高度增加 → 原
scrollTop对应的位置实际已不可见 - 容器高度变小，但内容未变 → 原
scrollTop可能超出scrollHeight - clientHeight，变成无效值 - 用
contentRect.height判断是否需滚动时，要排除 padding/border：它不包含这些，而clientHeight包含
如何安全地同步视口位置
核心逻辑是：在 ResizeObserver 回调中，仅当尺寸变化可能导致当前可视区域“失焦”时，才做最小化修正。不要每次 resize 都滚动，也不要直接设 scrollTop。
- 先缓存上一次的
scrollTop和scrollHeight，对比新旧clientHeight - 若新
clientHeightscrollTop + 可视高度，则说明顶部已滚出，需修正：取Math.min(scrollTop, scrollHeight - clientHeight) - 如需保持光标可见（比如配合
getSelection().focusNode），应在requestAnimationFrame中执行滚动，避开 layout 陷阱 - 避免在回调中读取
offsetHeight或getBoundingClientRect()—— 它们会强制同步 layout，抵消 ResizeObserver 的性能优势
const ro = new ResizeObserver(entries => {
for (const entry of entries) {
const { target } = entry;
const { clientHeight, scrollHeight, scrollTop } = target;
const maxScroll = Math.max(0, scrollHeight - clientHeight);
if (scrollTop > maxScroll) {
requestAnimationFrame(() => {
target.scrollTop = maxScroll;
});
}
}
});
ro.observe(document.getElementById('editor-container'));容易被忽略的边界情况
编辑器常嵌套在 flex/grid 容器中，且可能动态切换 display: none 或 visibility: hidden。ResizeObserver 对后者完全无感，对前者会静默失败（因为元素未参与 layout）。更糟的是，某些富文本编辑器（如 Slate、Tiptap）会在内部包裹一层 div[contenteditable]，你 observe 的外层容器尺寸不变，但内层因字体加载或行高计算导致真实内容区溢出——这时必须 observe 实际可滚动的子节点，而非父容器。
立即学习“前端免费学习笔记（深入）”；
