ResizeObserver 是监听 DOM 元素尺寸变化的唯一推荐方案，因其精准响应 layout 变更、避免误判与性能问题；window.resize 仅响应视口变化，无法捕获 flex 布局、内容撑开等内部尺寸变更。
ResizeObserver 是唯一推荐的方案，其他方法要么监听错对象（比如 window.resize），要么性能差、易漏判、逻辑绕弯。
为什么不能用 window.addEventListener('resize')
这个事件只响应浏览器视口变化，跟 DOM 元素内部尺寸毫无关系。常见误判场景包括：
• Flex 子项因 flex-grow 被压缩宽度
• 卡片插入新内容后高度自动撑开
• 侧边栏展开导致相邻容器宽度重算
• visibility: hidden 切换后回流
这些情况下 window.resize 都不会触发——它根本不知道发生了什么。
ResizeObserver 必须等元素挂载后再调用 observe()
如果目标元素还没出现在 DOM 中（比如 Vue/React 组件还没 mounted，或 JS 执行早于 HTML 解析），observe() 会直接报错：Failed to execute 'observe' on 'ResizeObserver': The target must be an instance of Element。
实操要点：
• 原生 JS：放在 DOMContentLoaded 回调里，或确保 document.getElementById('xxx') 返回非 null 后再调用
• React：写在 useEffect(() => { ro.observe(el); return () => ro.unobserve(el); }, []) 中
• Vue：在 mounted() 钩子里执行，SSR 场景下加 if (typeof document !== 'undefined') 防报错
• 动态插入的元素（如 innerHTML 或 appendChild）必须等插入完成再 observe()，否则静默失效
回调里改 target 尺寸会触发无限循环
ResizeObserver 回调是同步响应 layout 变更的，一旦你在里面直接改 element.style.width、element.style.padding 或 element.style.display，就会再次触发 layout 计算，进而再次进入回调——页面卡死或崩溃不是夸张。
安全做法：
• 只读取 entry.contentRect.width 和 entry.contentRect.height（它们代表 content-box 尺寸，稳定且不触发重排）
• 更新状态、切换 class、设置 CSS 自定义属性（如 el.style.setProperty('--width', width + 'px')）
• 如需调整尺寸，改兄弟元素或父容器，避开 entry.target 自身
• 必须同步修改时，用 requestAnimationFrame 推迟到下一帧，别硬刚
contentRect 不含 padding/border，别拿它算总占位
entry.contentRect.width 永远只返回内容区域尺寸，和 box-sizing 无关。例如：width: 300px; padding: 20px; border: 4px solid 下，contentRect.width 是 252（300 − 20×2 − 4×2），不是 300。
常见踩坑点：
• 用 contentRect 值去对齐带 padding 的布局 → 位置偏移
• 监听一个纯靠 padding 撑高的空 div → contentRect.height 始终为 0，回调永不触发
• 想检测 border 变更 → 它根本不响应，因为 border 不改变 content area
若真需要总占用尺寸（含 padding + border），可搭配 getBoundingClientRect()，但注意它会强制同步 layout，高频回调中慎用
立即学习“前端免费学习笔记（深入）”；
组件卸载时没调disconnect() 或 unobserve()，ResizeObserver 实例会持续持有 DOM 引用，回调可能在节点销毁后仍执行，引发 Cannot read property 'xxx' of null 类错误——这点容易被忽略，但线上故障常源于此。 
