onresize是窗口尺寸变化的触发信号，非自适应工具；需手动绑定事件、节流处理、避免覆盖和内存泄漏，并结合业务逻辑判断是否响应。
onresize 属性不是用来“自适应调整”的工具，它只是一个触发信号——窗口尺寸变了，它就 firing 一次（或多次），至于怎么响应、要不要响应、响应后干啥，全靠你自己写逻辑。
onresize 是事件属性，不是 CSS 或布局机制
它不改变任何样式、不重排元素、也不自动缩放内容。它的作用非常单纯：通知你“尺寸变了”。常见误用是以为加个 onresize="doSomething()" 就能实现响应式，结果发现函数根本没执行，或者执行了但页面还是错位。
-
onresize只支持少数元素，实际可用的几乎只有<body>和window对象（window.onresize更常用） - 直接写在 HTML 标签里（如
<body onresize="...">）兼容性虽好，但无法动态解绑，也不利于维护 - 现代开发中，
window.addEventListener('resize', handler)是更可控的选择，尤其在单页应用里
resize 事件高频触发，不节流会卡死 UI
浏览器在拖动窗口边缘时，resize 事件可能每秒触发几十次。如果你在回调里直接调用 echarts.resize()、重算布局或触发 Vue forceUpdate，页面大概率会卡顿甚至假死。
- 必须加节流（throttle）：用
setTimeout+ 标志位，或 Lodash 的throttle，延迟 100–250ms 再执行真正逻辑 - 避免在回调里重复初始化实例（比如反复调用
echarts.init()），应复用已有实例再.resize() - Chrome 中
window.onresize有时会双触发，不是 bug，是渲染管线行为；节流能自然覆盖这个问题
Vue / React 项目里别裸用 window.onresize
在组件级监听 resize 时，直接赋值 window.onresize = handler 是危险操作：它会覆盖其他组件设的 handler，且卸载时不会自动清理。
立即学习“前端免费学习笔记（深入）”；
- 推荐在
mounted（Vue）或useEffect（React）里用addEventListener，并在beforeUnmount/useEffect cleanup中显式removeEventListener - 不要在 handler 里直接用
this（Vue）或闭包外的setState（React），容易引发内存泄漏或状态错乱；用箭头函数或绑定上下文 - 如果多个组件都需要响应尺寸变化，建议统一监听一次，把宽度/高度存入全局状态（如 Pinia / Context），各组件只
watch或useContext
真正难的不是监听 resize，而是判断“这次变化是否值得响应”——比如只是开发者工具开关导致的宽度微调，或者移动端键盘弹出引起的 viewport 高度变化，这些场景下盲目重绘反而破坏体验。节流只是基础，业务逻辑里的判定条件才是关键。
