窗口resize事件需防抖，推荐延迟200ms；初始化后立即调用resize()避免闪动；优先用ResizeObserver替代window.resize；防抖回调中应优化逻辑而非仅控制时机。
窗口缩放（resize）事件默认高频触发，拖拽调整窗口时每秒可达数十次。直接在回调里执行图表重绘、布局计算或 DOM 重排，极易引发卡顿、掉帧甚至主线程阻塞。防抖不是“可选项”，而是必须手段——关键在于怎么用对、用准。
选对延迟值：150–250ms 是黄金区间
延迟太短（如 50ms），用户还在拖拽就反复触发，视觉上仍有抖动；延迟太长（如 500ms），松手后明显等待，交互滞后感强。
- 起始推荐设为 200ms，覆盖大多数桌面设备和常规网络环境
- 高刷屏（120Hz+）或触控平板可微调至 150ms，提升响应跟手度
- 避免使用固定 300ms 或更高值，除非业务逻辑极其复杂且用户容忍度高
必须手动触发首次 resize
防抖只管“变化之后”，不管“初始渲染”。若等 resize 事件才调 chart.resize()，图表会先按默认尺寸（比如 600×400）绘制，再缩放，造成闪动、错位或内容溢出。
- ECharts / Chart.js 初始化完成后立即调用
resize() - 确保容器 DOM 已挂载、CSS 尺寸已计算，可用
requestAnimationFrame包一层更稳妥 - 不要依赖“第一次 resize 自动触发”——它根本不会来
优先用 ResizeObserver 替代 window.resize
window.addEventListener('resize', ...) 监听的是整个浏览器窗口，但多数场景真正关心的只是某个容器元素的宽高变化。ResizeObserver 更精准、更轻量、天然低频。
立即学习“Java免费学习笔记（深入）”；
- 它只在目标元素盒模型真实变化时触发，浏览器自动合并连续变更
- 无需防抖也能稳定运行；若内部逻辑较重，再叠加 200ms 防抖即可
- 兼容性已覆盖 Chrome 64+、Firefox 69+、Safari 13.1+、Edge 79+；IE 不支持，但可 fallback 到 window.resize
防抖回调里别做重活
防抖控制的是执行时机，不是执行效率。如果每次 resize 后都要深克隆配置、遍历上千条数据、重算坐标轴，再快的防抖也救不了。
- ECharts 推荐用
setOption(..., { notMerge: true }) + resize()组合，跳过全量重绘 - Chart.js 可在
update({ duration: 0 })中关闭动画，提速明显 - 避免在回调中同步请求接口、操作大量 DOM 或触发强制重排
