ResizeObserver 与 MutationObserver 实战：监听元素尺寸与 DOM 变化（告别轮询）

我至今记得那个让我加班的周五下午。当时我在做一个数据看板，左边是一棵树形菜单，右边是一坨图表，需求很简单：窗口变大图表跟着变大，窗口变小图表跟着变小。我脑子都不带转的，直接window.addEventListener('resize', redraw)，本地拖了拖浏览器边框，一切完美，提测，下班，美滋滋。

结果测试同学在群里 @ 我：「哥，你这图表怎么有时候不刷新啊？」我一头雾水，远程过去一看，他是点了左侧菜单的折叠按钮——侧边栏一收，右边容器宽度瞬间变了，但浏览器窗口压根没动。我的 resize回调当然一声不吭，图表还停留在刚才的宽高上，丑得像没加载完。那一刻我才意识到，我以前对「监听变化」这件事的认知，基本是建立在沙堆上的。

更丢人的是另一件事。有个动态评论区，新消息进来要自动滚到底部，我二话不说写了个setInterval(() => checkScroll(), 200)，每 200 毫秒轮询一次，硬生生把页面搞出了肉眼可见的卡顿。后来才知道，浏览器早就把这两类需求对应的答案端到脸前了：管尺寸的叫 ResizeObserver，管 DOM 结构/属性变化的叫 MutationObserver。这俩货，就是专门用来「告别轮询」的。

这篇文章不是 API 文档的搬运，而是把我踩过的坑、掉过的头发、以及这俩观察者到底该怎么用、怎么避坑，一次性讲清楚。如果你也曾经用 setInterval去猜元素变没变，或者以为MutationObserver能监听到尺寸变化，那这篇就是写给你看的。

顺带说一句，为什么我们这帮前端一遇事就想着轮询？说白了是路径依赖——window.resize和setInterval 是我们刚入行就会的两把锤子，看见「变化」这颗钉子就下意识抡上去。而 ResizeObserver 和 MutationObserver 这俩是后来才进标准、课本和培训班又很少讲，属于「知道的人觉得理所当然、不知道的人永远在重复造轮子」的典型。我带过的实习生里，十个有八个的第一版监听方案都是 setInterval，问起来都说「能用就行」——能用，和用得对，中间隔着一条性能的深沟。

一、先理清一个最容易被搞混的点

很多人（包括当年的我）会下意识觉得：都是「观察 DOM 变化」的 API，随便挑一个用不就行了？错，而且错得离谱。这俩观察者的「关注点」是完全正交的：

• ResizeObserver 只关心一件事——一个元素盒子（content box / border box）的尺寸变了没，宽高变了它才响。
• MutationObserver 关心的是 DOM 树的结构、属性、文本变了没，比如你给节点加了个子元素、改了class、动了innerHTML，它才会响。

注意，一个元素尺寸变了，并不等于它的 DOM 结构或属性变了。比如 CSS 媒体查询让某个容器从 800px 变成 400px，DOM 一个字节没动，MutationObserver 连眼皮都不会抬一下。反过来，你给一个 position: fixed 的弹窗加了一个子节点，DOM 结构变了，但尺寸可能纹丝不动，ResizeObserver 也无动于衷。

划重点：它们不是替代关系，是各管一摊的互补关系。当年我拿 MutationObserver 去「监听元素大小」，纯属缘木求鱼——除非你每次改尺寸都顺手改了 style.width 这种内联属性，那它碰巧能捕捉到 attribute 变化，但这根本不是尺寸观测的正确姿势，性能也稀烂。

打个可能不严谨但好记的比方：ResizeObserver 像是给元素装了把「游标卡尺」，尺寸一丁点地变它都报；MutationObserver 像是给 DOM 树派了个「户籍警」，谁家添了人口、改了门牌号、换了户口本，它都记。你不能用游标卡尺去查谁家生了娃，也不能指望户籍警告诉你这堵墙厚度变了——工具选错，再努力也是白搭。这也是为什么我开头那个看板 bug 修了好几个小时：我拿户籍警干游标卡尺的活，能不出事吗。

聊完区别，你可能会嘀咕：我自己写个setInterval 每 100 毫秒读一次 offsetWidth，不行吗？行，但这笔账你未必算得清。setInterval 不管元素变没变都会准时敲门，页面静止时它还在白白占用主线程；更阴险的是，如果你在回调里又读又写样式，每次都触发一次同步布局（forced reflow），几个轮询叠一起，帧率直接被拖垮。而 ResizeObserver 和 MutationObserver 是「变了才通知、且浏览器自动把一批变动合并成一次回调」，本质上是事件驱动而非时间驱动。一个靠天吃饭，一个靠地吃饭，高下立判。当年我那个 200 毫秒轮询的评论区，打开 Chrome 的 Performance 面板一看，主线程一条条红色长条，惨不忍睹。

想看更系统化的「几种监听方式横评」？其实浏览器这套观察者家族还有好几位成员，比如做性能监控的Performance API 实战：用 Navigation/Resource Timing 做前端性能监控（Web Vitals） 那篇里提到的 PerformanceObserver，跟它俩算同门师兄弟。但今天，我们先把尺寸和 DOM 这两位主角吃透。

二、ResizeObserver：专治「元素尺寸变化」

2.1 它解决了什么痛点

在没有 ResizeObserver 的年代，你想监听某个具体元素（不是窗口）的尺寸变化，几乎只能：

1. 监听window.resize，再手动读那个元素的offsetWidth去对比——但前面说了，窗口没动、容器自己变了，你啥也收不到；
2. 上setInterval轮询，纯纯的性能自杀；
3. 用ResizeObserver 的 polyfill（早期靠 MutationObserver+transitionend+window.resize三件套硬凑）。

ResizeObserver 是浏览器原生提供的、异步的、自动合并变动的尺寸观测器。它最香的地方在于：回调里修改被观察元素的尺寸不会立刻又触发一次回调，浏览器用「跨帧两阶段投递」的机制兜住了无限循环（Chrome 默认递归深度限制 16 层，超了会报 ResizeObserver loop limit exceeded，但你的页面不至于直接卡死）。这一点，轮询和手搓方案根本给不了。

2.2 最小可用代码

javascript
复制
运行
// 拿到我们要盯着的那块容器const box = document.getElementById('dashboard');// 创建一个 ResizeObserver，回调里拿到的是 entries（变化记录数组）const ro = new ResizeObserver((entries) => { // 一次回调可能包含多个被观察元素的变化，所以要遍历 for (const entry of entries) { // entry.target 就是发生变化的那个元素本身 // entry.contentRect 是变化后的「内容盒子」尺寸信息（只读 DOMRectReadOnly） const { width, height } = entry.contentRect; console.log('容器尺寸变了 →', width, height); // 在这里做你的响应式逻辑，比如重绘图表、改布局 renderDashboard(width, height); }});// 开始观察目标元素，observe 可以多次调用观察不同元素ro.observe(box);// 用完了记得收手：只取消对某一个元素的观察// ro.unobserve(box);// 或者一刀切，取消当前 observer 对所有元素的观察// ro.disconnect();

这段代码里几个东西必须记牢，都是真 API，别自己编：

• entry.target：触发变化的元素节点。
• entry.contentRect：一个DOMRectReadOnly，里面有width、height、top、left、x、y、bottom、right，是内容盒子（content box，不含 padding 和 border）的尺寸。
• 如果你需要 border box 或带 devicePixelRatio 的尺寸，还有 entry.borderBoxSize和entry.devicePixelContentBoxSize（后两者是ResizeObserverSize数组，处理多栏/多片段布局时才有意义，普通场景用contentRect就够了）。
• observe()、unobserve()、disconnect()三个方法，字面意思，记不住就背。

2.3 一个能让你原地去世的坑：回调里改尺寸

这是我见过的、也是我自己犯过的最经典的 ResizeObserver 反模式。你想着「尺寸变了，我顺便把高度按宽高比调一下」，于是在回调里直接改了被观察元素的高度：

javascript
复制
运行
// ❌ 错误示范：在回调里修改被观察元素自己的尺寸const ro = new ResizeObserver((entries) => { const entry = entries[0]; const width = entry.contentRect.width; // 这一行会触发新的 resize 事件，下一帧又进来，永动机诞生 entry.target.style.height = `${width * 0.75}px`;});// ✅ 正确姿势一：用 CSS 的 aspect-ratio 把宽高比交给布局引擎，别在 JS 里手改// .card { aspect-ratio: 4 / 3; }// ✅ 正确姿势二：实在要改，就改「子元素」，别碰被观察元素自身const ro2 = new ResizeObserver((entries) => { const entry = entries[0]; const width = entry.contentRect.width; // 只改内部子元素，被观察元素本身的尺寸不会因此再变，循环断掉 const content = entry.target.querySelector('.content'); if (content) { content.style.fontSize = width < 400 ? '14px' : '16px'; }});

说白了：回调里动被观察元素自己的几何属性，就是在和浏览器玩俄罗斯轮盘。哪怕浏览器有 16 层兜底，每层都是一次重排（reflow），积少成多照样卡成 PPT。

我第一次踩这个坑，是在做一个自适应卡片墙：每张卡片宽度随容器变，高度我想按 4:3 自动算，于是顺手在回调里写了 card.style.height = width * 0.75 + 'px'。本地拖了几次没看出毛病，上线后用户反馈「页面滚着滚着自己抖」。后来才反应过来，高度一变又触发尺寸回调，浏览器为了不让你死循环，把多出来的通知挪到了下一帧，于是每帧都在「改高度→重排→再触发→再改」，肉眼可见的抽搐。换成 CSS 的 aspect-ratio 之后，世界一下子清净了——布局引擎替我管宽高比，JS 彻底不碰几何属性，循环从根上断掉。

2.4 重绘/重算往哪放？requestAnimationFrame 了解一下

ResizeObserver 的回调本身是异步的，但如果你在里面做重排密集的操作（比如读 offsetHeight又写样式），很容易在一帧内制造多次布局抖动。稳妥的做法是把真正「读-写」分离，或者把重绘丢进requestAnimationFrame：

javascript
复制
运行
const ro = new ResizeObserver((entries) => { const entry = entries[0]; // 把重绘安排到下一帧，避免和当前帧的布局计算打架 requestAnimationFrame(() => { drawChart(entry.target, entry.contentRect.width, entry.contentRect.height); });});

如果图表重算特别重，重到会阻塞主线程，那更狠的招是把计算丢给Web Workers 实战：把计算密集型任务丢给后台线程（SharedWorker 与多线程通信） 里讲的 Worker，主线程只负责拿结果画画——不过那是后话，大多数项目用 rAF 就够体面了。

2.5 兼容性：放心用，但老古董要当心

现代浏览器对 ResizeObserver 的支持已经非常成熟，Chrome 64+、Firefox 69+、Safari 13.1+、Edge 79+ 全部覆盖。如果你还在伺候 IE（愿天堂没有 IE），那是真不支持，得上官方 polyfill（resize-observer-polyfill）。MDN 上有完整的浏览器兼容表，需要精确到具体版本时可以翻 ResizeObserver - MDN。我个人的经验是：面向 2020 年以后的项目，直接原生用，别浪费生命写兼容分支。

不过也得泼盆冷水：ResizeObserver 不是万能锤。如果你只是想做整页级的响应式（纯窗口变化），那 CSS 媒体查询加 window.resize 反而更轻更直观，犯不着给每个元素都挂一个 observer。ResizeObserver 的真正主场，是「某个具体容器、图表、弹层的尺寸变化，没法用窗口事件表达」的场景。工具趁手的前提，是先分清楚战场在哪。

三、MutationObserver：专治「DOM 结构/属性/文本变化」

3.1 它到底能看什么

MutationObserver 是 DOM 变动的「监听器」。子节点增删、属性改动、文本内容变化，它都能通知你。它的强大之处在于可以精确配置你想看哪类变动，而不是一股脑全收。先记住这张配置表（全是真字段，默认值也给你标好了）：

3.2 最小可用代码

javascript
复制
运行
// 目标节点，比如一个会动态被塞内容的容器const feed = document.getElementById('feed');// 创建 MutationObserver，回调函数拿到 (变动记录数组, observer 自身)const mo = new MutationObserver((mutations, observer) => { // 一次 DOM 变动可能被浏览器「微任务批处理」合并成一批记录，所以要遍历 for (const mutation of mutations) { // mutation.type 告诉你这次是哪种变动：'childList' / 'attributes' / 'characterData' if (mutation.type === 'childList') { // 新增的节点在 addedNodes 里，删掉的在 removedNodes 里 mutation.addedNodes.forEach((node) => { if (node.nodeType === Node.ELEMENT_NODE) { console.log('来了个新节点：', node); bindEvents(node); // 比如给新插入的按钮绑事件 } }); } else if (mutation.type === 'attributes') { // 哪个属性变了写在 attributeName 里，旧值（如果开了 attributeOldValue）在 oldValue console.log(`属性 ${mutation.attributeName} 变了，旧值是 ${mutation.oldValue}`); } }});// 配置要监听的变动类型，这里只盯子节点和属性，并且扩展到子树mo.observe(feed, { childList: true, // 子节点增删 attributes: true, // 属性变化 subtree: true, // 连子孙节点一起看});// 用完收手// mo.disconnect();// 偷偷说一句：mo.takeRecords() 能立刻把还没投递的变动记录取出来并清空队列

几个真 API 再敲黑板：mutation.addedNodes/removedNodes（NodeList）、mutation.attributeName、mutation.oldValue、mutation.target、mutation.previousSibling/nextSibling；observer 层面的 observe()、disconnect()、takeRecords()。一个都别瞎编。

3.3 两个容易踩的细节

细节一：MutationObserver 是「微任务批处理」的。 你连续改了十次 DOM，浏览器不会傻乎乎调你十次回调，而是把这些变动攒成一批 MutationRecord，在下个微任务里一次性丢给你。所以千万别假设「一条记录对应一次用户操作」——一条记录可能包裹着一堆操作。当年我为了「每次新增一条就滚动一下」写了个累加器，结果攒批之后一次滚了八条，差点把页面弹飞。

细节二：attributeFilter是降本增效神器。如果你只想盯位置变化（位置变化归根结底是style或class变了），就别开裸的attributes: true全量监听，精准一点：

javascript
复制
运行
// 只盯 style 属性的变化，其他属性（比如你顺便改了个 data-*）一律无视const mo = new MutationObserver((mutations) => { for (const m of mutations) { if (m.attributeName === 'style') recomputePosition(); }});mo.observe(panel, { attributes: true, attributeFilter: ['style'] });

这种「只观察 style」的写法，我在做浮层定位（Overlay）时天天用——源元素位置一变我就重算浮层坐标，比挂 resize+scroll两个全局监听优雅多了，也不容易漏。

3.4 它不该干什么

说句得罪人的实话：MutationObserver 很好用，但它不是你做业务状态同步的首选。别拿它去监听你自己框架管着的 DOM 然后反向推导状态——React/Vue 的响应式系统才是「唯一真值」，MutationObserver 只是个「补锅匠」，最适合补的是第三方脚本往你 DOM 里塞东西这类你控制不到的场景（比如埋点 SDK 注入的节点、富文本编辑器内部变动、别人家的组件内部 DOM 抖动）。主线业务逻辑，老老实实走事件委托和数据驱动。

3.5 兼容性兜底：MutationObserver 资格更老，更放心

顺带把兼容性也交代了，省得你心里一直打鼓。MutationObserver 的资历比 ResizeObserver 老得多，IE11 起就原生支持（更早的 IE 只能靠 DOMSubtreeModified 这种已被废弃的事件，或者上 polyfill），Chrome 26+、Firefox 14+、Safari 7+ 全绿。换句话说，但凡你还需要兼容的浏览器还没灭绝，MutationObserver 都能直接上手，不用犹豫。MDN 上的 MutationObserver - MDN 有逐版本对照表可以查。我的经验法则就一句：尺寸观测用 ResizeObserver（新但稳），结构/属性观测用 MutationObserver（老且稳），两者加起来，能覆盖你日常 99% 的「监听变化」需求，剩下的 1% 才轮到 getBoundingClientRect加定时器的无奈之举。

四、实战案例：把俩货真正用起来

光讲 API 等于没讲。下面两个案例是我从真实项目里扒出来的最小骨架，能跑、能懂。

4.1 案例一：响应式图表（ResizeObserver 主场）

图表容器一变宽，图表就重绘，这是 ResizeObserver 的标准用例：

javascript
复制
运行
// 假定页面上有个 <div id="chart"> 用来装图表const container = document.getElementById('chart');let chartInstance = null; // 你的图表库实例（ECharts / Chart.js 之类的）const ro = new ResizeObserver((entries) => { const entry = entries[0]; const { width, height } = entry.contentRect; // 容器太小时没必要画，避免无意义重绘 if (width === 0 || height === 0) return; // 真正重绘：先 resize 再 render，具体 API 看你用的库 requestAnimationFrame(() => { if (chartInstance) { chartInstance.resize(width, height); } drawChart(container, width, height); // 自绘 canvas 的话就走这里 });});ro.observe(container);

这里有个隐藏的「人味」经验：容器在display: none切回display: block 的瞬间，尺寸会从 0 跳到一个正常值，回调会触发一次。所以加个 if (width === 0) return的守卫，能救你无数次诡异的「首帧画歪了」。我在一个后台管理项目里就吃过这个亏：标签页切换用v-show 控制显隐，图表在隐藏态就被初始化，拿到的尺寸全是 0，画出来一团乱麻，切到可见才突然正常——后来把这个守卫加上，再配合「切到可见时重新 observe 一次」，才彻底根治。这种坑你不去踩一遍，看文档是永远想不到的。

4.2 案例二：动态消息列表自动滚底（MutationObserver 主场）

新消息进来，列表自动滚到底部，再也不用setInterval轮询：

javascript
复制
运行
// 消息列表容器const list = document.getElementById('message-list');const mo = new MutationObserver((mutations) => { let hasNew = false; for (const m of mutations) { // 只要有子节点被加进来，就认为来了新消息 if (m.type === 'childList' && m.addedNodes.length > 0) { hasNew = true; break; } } if (hasNew) { // 滚到最底，nextTick 保证 DOM 已经插进去了再滚 requestAnimationFrame(() => { list.scrollTop = list.scrollHeight; }); }});mo.observe(list, { childList: true, // 只盯子节点增删，够了 subtree: true, // 子孙也要看，万一新消息包在子容器里});

顺便提一句，新消息本身往往是通过请求拉来的。如果你的列表数据是用流式接口一点一点推的，建议配合Fetch + AbortController + Streams 实战：现代请求的中断与流式读取（进度/取消） 那套把数据边收边渲染，再交给这里的 MutationObserver 做滚动——职责清晰，谁也不抢谁的活。

4.3 案例三：一个浮层既要跟尺寸又要跟 DOM（俩一起上）

真实业务里，浮层（tooltip / popover）经常既要跟着源元素的位置（位置变 = style/class 变，MutationObserver 管），又要跟着容器尺寸重排（ResizeObserver 管）。这俩就得一起上，而且务必在组件销毁时一起 disconnect：

javascript
复制
运行
// 源元素（触发浮层的按钮/输入框）const origin = document.getElementById('origin');// 浮层本身const panel = document.getElementById('panel');// 位置变化：用 MutationObserver 只盯 style（位置本质是 transform/left/top 变了）const originObserver = new MutationObserver(() => positionPanel());originObserver.observe(origin, { attributes: true, attributeFilter: ['style', 'class'] });// 尺寸变化：用 ResizeObserver 盯浮层自己，尺寸一变就重排const panelObserver = new ResizeObserver(() => positionPanel());panelObserver.observe(panel);function positionPanel() { // 这里写你的定位算法：读 origin 的 getBoundingClientRect，算 panel 的 left/top const rect = origin.getBoundingClientRect(); panel.style.left = `${rect.left}px`; panel.style.top = `${rect.bottom + 4}px`;}// ⚠️ 组件卸载时必须一起收摊，漏一个都是内存泄漏function destroy() { originObserver.disconnect(); panelObserver.disconnect();}

如果你是用 Vue，把 destroy丢进onBeforeUnmount；如果是 React，把两个 observe放进useEffect，disconnect 丢进它的 cleanup 函数。我早年就是忘了 disconnect，一个弹窗关了又开，observer 越积越多，内存曲线跟过山车似的，被同事笑了一个 sprint。

五、最佳实践清单（血泪总结）

把上面散落的坑收一收，给你一份我自己的「保命清单」：

1. 别观察document.body或整个页面。把MutationObserver的观察范围缩到最小的目标节点，只开你真要的变动类型（childList/attributes/characterData别全开）。观察整个document.body 是性能灾难，框架自己的虚拟 DOM 更新都会往你回调里灌。
2. ResizeObserver 回调里别改被观察元素自身的尺寸。改子元素、用aspect-ratio、或者用 rAF 把重绘推到下一帧，三选一。
3. 组件/页面卸载时一定disconnect()。 这是最容易忘、也最伤的一条。Observer 不主动停止，它引用的 DOM 和闭包状态就一直活着，内存泄漏找都找不到。
4. 重绘/重算丢requestAnimationFrame。 读-写分离，避免一帧内多次布局抖动。重活考虑 Worker。
5. MutationObserver 的记录是批处理的，别指望一对一。需要「逐条处理」时自己写个增量累加器，或者用takeRecords()主动Flush。
6. 别拿 MutationObserver 做业务状态同步。 它是补第三方 DOM 变动的，主线还是走框架响应式。
7. 老浏览器上 ResizeObserver 用官方 polyfill。别自己造轮子，早期那个靠MutationObserver + transitionend + 定时器 硬凑的 polyfill 就是现成的反面教材。

说到自定义绘制，如果你的响应式重绘还想更进一步，突破原生 CSS 画不出东西的限制，可以看看 CSS Houdini 实战：用 Paint/Animation Worklet 突破原生 CSS 限制（自定义绘制）——不过那是另一个坑，今天先打住。

六、它俩和 SPA 路由那点事

最后顺带一提：在单页应用里，路由切换本质就是 DOM 结构的大换血。如果你需要在「某个路由视图挂载后」做点事，用 MutationObserver 去盯根节点确实能办到，但更地道的是直接 Hook 路由的 lifecycle。话说回来，要是你想让路由切换本身丝般顺滑、连视图过渡动画都包圆了，那得靠 View Transitions API 实战：给 SPA 路由切换加上丝滑的视图过渡动画那位主角，跟本文的俩观察者算上下游关系——它管「切换得好不好看」，我们管「变化发生了没有」。

七、小结

回到开头那个让我加班的周五。如果时光倒流，我会这么写：

• 容器尺寸变 → 上 ResizeObserver，别碰window.resize，更别轮询；
• DOM 结构/属性变 → 上 MutationObserver，精确配置childList/attributes/attributeFilter，别全量开；
• 它俩是互补的，一个看「盒子大小」，一个看「树怎么动」，谁也替代不了谁；
• 用完一定disconnect()，重绘丢rAF，回调里别动被观察元素自己的尺寸。

轮询是懒人的临时解，观察者是浏览器的正解。从setInterval里爬出来吧，你的主线程会感谢你的。如果这篇帮你少加了一次班，那我掉的那些头发，也算没白掉。

最后留个作业：打开你手头正在维护的项目，全局搜一下setInterval和window.addEventListener('resize'，凡是用来「监听某个元素变没变」的，基本都能换成今天讲的俩观察者。改完跑一遍 Lighthouse 或者 Chrome 的 Performance 面板，你会回来谢我的。前端这行，省下的每一帧、每一次重排，都是给用户手机的电池和钱包积德——这话听着像鸡汤，但卡顿真实存在，优化也真实有用，不是写给人看的漂亮话。

标签：javascript, 前端, css3描述：用第一人称踩坑经验讲清 ResizeObserver 与 MutationObserver 的本质区别——一个专盯元素尺寸变化、一个专盯 DOM 结构/属性/文本变化，两者互补而非替代。涵盖 API 用法、contentRect 与 MutationRecord 字段、无限循环反模式、attributeFilter 精准监听、rAF 重绘、组件卸载 disconnect 等实战要点，帮你彻底告别 setInterval 轮询。