做数据可视化大屏这两年我真是被 ECharts 的 resize 坑过太多次。最近又碰到一个非常典型的报错浏览器窗口一缩放控制台直接甩出一行红字Uncaught TypeError: Cannot read properties of undefined (reading ty)。这问题最烦人的地方在于它不是每次必现有时候页面来回切几下才冒出来光看报错根本定位不到是哪个图表。我花了大半天时间把项目里所有图表实例的生命周期和 resize 监听逻辑整体捋了一遍总算把来龙去脉搞得明明白白。这篇就把这个经典坑的根因、排查思路和几种不同场景下的解决方案完整整理出来给同样被 resize 折磨过的朋友一个直接的参考。1. 报错现场还原与现象分析1.1 这个报错最常出现在哪几类场景我复盘了手上几个出问题的项目发现这类报错的触发场景其实高度相似基本可以归成三类。第一类是路由切换或组件卸载之后窗口发生 resize。典型情况是后台管理系统里从订单列表页切到数据报表页或者从 A 页面切到 B 页面后用户拖动浏览器窗口大小控制台就报错了。这类场景下前一个页面的图表实例已经通过dispose()销毁但 window 上的 resize 监听器没有移除resize 事件一触发回调里还在调用旧图表的方法。第二类是弹窗或抽屉组件里的图表。很多系统里图表不是常驻页面的而是放在 Modal 或者 Drawer 里的打开的时候用v-if渲染容器关闭后容器被销毁。如果关闭弹窗时只处理了弹窗本身的关闭逻辑没有同步销毁图表实例和移除 resize 监听下次缩放窗口就会报错。而且这类场景还有个隐蔽问题容器销毁后图表实例持有的 DOM 引用已经是空壳了ECharts 内部做 resize 计算时读取容器尺寸或内部组件属性拿到 undefined 再往下访问立刻就炸。第三类是同一个容器被重复初始化。这种情况在动态渲染图表、或者在一个方法里被多次调用echarts.init(dom)时特别容易踩中。ECharts 对同一个 DOM 节点第二次调用init会返回第一次创建的实例并打印一条警告There is a chart instance already initialized on the dom。如果后续代码逻辑基于每次 init 都会返回新实例去处理新旧实例混在一起加上 resize 监听器绑定得又乱就会报这种 undefined 错误。1.2 报错信息拆解reading ty 到底是什么很多朋友看到reading ty会懵不知道这个ty是什么属性。实际上控制台里这个报错的完整形式绝大多数是Cannot read properties of undefined (reading type)ty大概率是错误文本在复制或展示时被截断了本质是在访问一个 undefined 对象的type属性。那 ECharts 内部哪里会读type这要从图表实例的数据结构说起。一个 ECharts 实例内部维护了组件对象比如 series、xAxis、yAxis、tooltip、legend 等每个组件对象上都有一个type字段标识自己是什么类型。调用resize()时图表需要重新计算布局遍历内部的组件视图数组依次读取每个组件的type来决定怎么更新。如果在某个操作之后这个组件对象已经是 undefined比如实例被销毁但内部状态没清干净或者容器被移除导致的内部 DOM 引用失效这一遍历就会直接抛 TypeError。还有一种可能是 resize 监听器绑定方式不对导致this指向异常。比如直接写window.addEventListener(resize, this.chart.resize)此时 resize 回调里的this已经不再指向 chart 实例执行时内部访问this._api或this._zr就是 undefined后续再往里访问属性也会出现类似报错。这类问题的共同规律就是resize 触发时代码访问了一个已经不存在或者指向错误的对象。2. 根因深度剖析图表实例的生命周期与 resize 机制2.1 ECharts init 到 resize 之间的内部逻辑要彻底理解这个报错得先把 ECharts 实例从创建到销毁的过程理一遍。调用echarts.init(dom)时ECharts 会做几件关键的事基于传入的 DOM 节点创建一个 zrender 实例这是 ECharts 底层的渲染引擎负责 Canvas/SVG 绘制初始化内部的事件绑定建立一个_api对象作为业务代码和内部组件的交互桥然后等待你调用setOption()去解析配置项、创建组件对象。调用setOption()时ECharts 会解析 option 里配置的 series、axis、tooltip 等生成对应的 model 和 view 对象这些对象上都有type属性标识类型全部挂到实例内部的_chartsMap、_componentsMap这些结构上。到这里图表才算真正绘制出来。调用resize()时ECharts 要做的是让图表重新适配容器尺寸。它会读取容器最新的宽高更新内部 zrender 视图的尺寸通知各个组件视图重新布局重绘。如果实例正常存活这个流程没问题但如果实例已经被dispose()销毁或者容器 DOM 已经被移除内部某些对象已经清理掉了resize 时再遍历组件对象去读type就会撞上 undefined。dispose()的时候ECharts 会做什么呢它会销毁 zrender 实例清空内部的事件监听把内部一些引用置空。有些情况下业务代码以为 dispose 之后图表就不存在了但 window 上的 resize 监听器还在里面还调用了图表实例的方法——这其实是把监听器的生命周期和图表实例的生命周期脱节了。打个比方图表实例像一台电视机dispose()是把电视机关掉并把内部零件拆除resize 监听器是墙上的遥控器。你关掉了电视但遥控器还连着电源每次按按钮resize 事件触发就会朝着一堆零件残骸发射信号当然会出问题。正确做法应该是关电视之前先把遥控器断电也就是先移除 resize 监听再 dispose 图表实例。2.2 两个最容易踩的坑this 丢失和监听遗忘第一个坑是 this 丢失。我在不同项目里见过好几次这种写法window.addEventListener(resize, this.chart.resize)这行代码表面上把 chart 的 resize 方法挂到了 window 的 resize 事件上但注意这里传入的是一个裸的函数引用。当 resize 事件触发时JavaScript 里普通函数调用时this指向 window而不是 chart 实例。于是 chart.resize 内部访问this._api之类的属性时拿到的是 window 上的同名属性大概率是 undefined再往下访问就报错了。解决方法是显式绑定 this或者用箭头函数包裹window.addEventListener(resize, () { this.chart.resize() })但这也带来了第二个坑箭头函数版本写起来方便但如果你在实例销毁时写的是window.removeEventListener(resize, this.chart.resize)这个移除是无效的因为移除的监听器是另一个函数引用。最终结果就是监听器移除不掉图表实例被销毁之后resize 事件仍然会触发一个孤儿回调。遇到这个问题我的建议是从一开始就用具名函数来绑定和移除监听器不要把匿名函数或者裸的实例方法直接扔给 window。这一步做好了能规避掉 80% 的 resize 相关报错。3. 一套通用的 resize 管理方案3.1 用 Map 统一管理图表实例项目里图表一多散落各处的 init 和 resize 逻辑就会变得非常难维护。我的做法是封装一个统一的EChartsManager用 Map 集中管理所有图表实例结构清晰也方便统一处理 resize。import * as echarts from echarts const chartMap new Map() export function createChart(dom, option) { // 如果这个 DOM 上已经有实例先销毁避免重复 init const existing echarts.getInstanceByDom(dom) if (existing) { existing.dispose() } const chart echarts.init(dom) chart.setOption(option) chartMap.set(dom, chart) return chart } export function destroyChart(dom) { const chart chartMap.get(dom) if (chart !chart.isDisposed()) { chart.dispose() } chartMap.delete(dom) }这里有个细节值得重点关注echarts.getInstanceByDom(dom)会返回该 DOM 上已存在的图表实例如果之前重复 init 过这个接口能帮你拿到旧的实例。用它做一次兜底销毁可以避免同一个容器上挂着多个实例互相打架。拿着这份统一管理代码resize 就能写得非常简单function handleResize() { chartMap.forEach((chart) { if (chart !chart.isDisposed()) { chart.resize() } }) } window.addEventListener(resize, handleResize)只要保证 createChart 和 destroyChart 成对出现并且全局只挂一次 resize 监听这个方案基本不会出幺蛾子。这也是我在大屏项目里的最终落地方案。3.2 resize 前做安全检查不管怎么统一管理总有机会遇到个别图表实例状态不对的情况。所以最稳妥的兜底就是在调用 resize 之前做一次判空和存活检查。ECharts 5 的图表实例自带isDisposed()方法专门判断实例是否已销毁。resize 前加上这层判断非常有必要function safeResize(chart) { if (!chart) return if (typeof chart.isDisposed function chart.isDisposed()) return chart.resize() }有些老项目用的 ECharts 版本比较旧实例上可能没有isDisposed()方法那就用chart.getDom()是否存在来判断function safeResize(chart) { if (!chart || !chart.getDom()) return chart.resize() }这里我多说一句很多人在 resize 回调里只做了一层if (chart)判空觉得 chart 有值就可以调用。但chart 有值 ≠ 实例活着。在组件销毁逻辑不正确的情况下chart 变量持有的实例可能已经被 dispose 了但变量本身还不是 null直接调用 resize 就会在内部走一个濒临崩溃的流程报出各种奇怪的 TypeError。isDisposed()才是判断存活的关键。3.3 加一个防抖避免频繁触发window resize 事件在拖拽窗口时会以极高的频率触发每个事件都去执行所有图表的 resize 重绘会造成不必要的性能开销。尤其大屏项目里图表多、SVG 或 Canvas 绘制量大频繁 resize 可能会导致页面卡顿甚至崩溃。常规做法是给 resize 事件加防抖。我常用的防抖函数大概这样的function debounce(fn, delay 200) { let timer null return function (...args) { if (timer) clearTimeout(timer) timer setTimeout(() { fn.apply(this, args) }, delay) } } const handleResize debounce(() { chartMap.forEach((chart) { if (!chart.isDisposed()) { chart.resize() } }) }, 200) window.addEventListener(resize, handleResize)防抖延迟我一般设定在 150ms 到 300ms 之间。太短起不到聚合效果太长会让用户感觉图表跟不上窗口变化。个人经验是 200ms 是个比较均衡的值肉眼几乎感知不到延迟又不会在连续拖拽时疯狂重绘。需要留意的是加了防抖之后窗口缩放结束前图表不会立刻跟着变这是正常现象。如果你的项目对图表的实时响应要求特别高比如地图拖拽、缩放联动这类场景可以考虑改用 requestAnimationFrame 来做节流但那种实现复杂度会高一些普通业务用防抖已经足够。3.4 进阶方案用 ResizeObserver 监听容器尺寸变化window resize 只能感知到窗口大小变化但实际开发中还有一些更隐蔽的尺寸变化比如侧边栏折叠、面板展开收起、弹窗尺寸动态调整这些场景里 window 尺寸根本没变但图表容器的大小变了。如果只挂 window resize 监听图表不会自动刷新。解决这个问题推荐使用ResizeObserverAPI它可以直接监听某个具体 DOM 元素的尺寸变化是比 window resize 更精准的方案。const dom document.getElementById(chartContainer) const chart echarts.init(dom) const observer new ResizeObserver(() { if (!chart.isDisposed()) { chart.resize() } }) observer.observe(dom) // 销毁时断开观察 function destroy() { observer.disconnect() chart.dispose() }要注意observer.observe(dom)的dom必须是图表容器元素。如果容器在布局中显示正常尺寸变化能被捕获但如果容器本身被display: noneResizeObserver 也会拿到一个 0 尺寸此时调用 resize 可能引发另一个隐患这个我在后面第 4.3 节专门展开。ResizeObserver 的浏览器兼容性现在已经很好了现代浏览器基本都支持项目里有 Babel 转译的话可以直接用。4. Vue 与 React 中的标准写法4.1 Vue 3 组合式 API封装一个 useEChartsVue 项目里报这个错十有八九是组件销毁时监听器没清理干净。这里给出一个我在 Vue 3 项目中常用的组合式函数封装把 init、resize、dispose 的生命周期全部管理起来。// useECharts.js import * as echarts from echarts import { onMounted, onBeforeUnmount, shallowRef } from vue export function useECharts(domRef, option) { const chartRef shallowRef(null) let resizeHandler null function init() { if (!domRef.value) return chartRef.value echarts.init(domRef.value) chartRef.value.setOption(option) resizeHandler () { if (chartRef.value !chartRef.value.isDisposed()) { chartRef.value.resize() } } window.addEventListener(resize, resizeHandler) } function setOption(newOption) { if (chartRef.value !chartRef.value.isDisposed()) { chartRef.value.setOption(newOption) } } function dispose() { if (resizeHandler) { window.removeEventListener(resize, resizeHandler) resizeHandler null } if (chartRef.value !chartRef.value.isDisposed()) { chartRef.value.dispose() chartRef.value null } } onMounted(init) onBeforeUnmount(dispose) return { chartRef, setOption, dispose } }在组件里这样使用template div refchartRef stylewidth: 100%; height: 400px/div /template script setup import { ref, watch } from vue import { useECharts } from /hooks/useECharts const chartRef ref(null) const { setOption } useECharts(chartRef, { /* option */ }) watch(() props.data, (data) { setOption({ series: [{ data }] }) }, { deep: true }) /script这套封装的精髓在于resizeHandler是具名函数并且放在闭包变量里dispose 时能保证 remove 掉同一个函数引用。同时 dispose 里先移除监听再销毁实例顺序也不会错。我自己多个项目实测下来基本没有再出现过 resize 相关报错。Vue 2 的选项式 API 也同理核心就是beforeDestroy钩子里先removeEventListener再chart.dispose()。关键点永远那几个移除监听、实例判空、顺序正确。4.2 ReactuseEffect 清理函数是关键React 里写的时候最常见的错误是把监听器绑在 effect 外面或者忘了在清理函数里移除。正确写法是把 resize 监听和 dispose 全放进同一个 useEffect 里。import * as echarts from echarts import { useEffect, useRef } from react function ChartComponent({ option, className }) { const domRef useRef(null) const chartRef useRef(null) useEffect(() { if (!domRef.current) return chartRef.current echarts.init(domRef.current) chartRef.current.setOption(option) const handleResize () { if (chartRef.current !chartRef.current.isDisposed()) { chartRef.current.resize() } } window.addEventListener(resize, handleResize) return () { window.removeEventListener(resize, handleResize) if (chartRef.current !chartRef.current.isDisposed()) { chartRef.current.dispose() chartRef.current null } } }, []) useEffect(() { if (chartRef.current !chartRef.current.isDisposed()) { chartRef.current.setOption(option) } }, [option]) return div ref{domRef} className{className} style{{ width: 100%, height: 400 }} / }这里有两个常见问题要注意。第一个如果option变化频繁且每次都整个替换配置图表内部重绘开销比较大而且如果新 option 里没有某些组件而旧 option 里有ECharts 默认会合并而不是清空。需要完全覆盖时要先chart.clear()再setOption()。第二个React 18 的 StrictMode 下useEffect 会执行两次导致组件挂载时 init 两次。这里的清理函数恰好能在第二次挂载前把第一次的实例销毁掉所以只要严格按照上面这个模式写StrictMode 下也不会报错。如果你在 React 19 或 StrictMode 下还遇到重复 init 问题可以检查一下是不是 useLayoutEffect 和 useEffect 混用了或者在 init 前用echarts.getInstanceByDom做一次兜底。4.3 一个容易忽略的问题容器尺寸为 0这个坑我栽过一次场景是一个图表放在 Tabs 切换的标签页里默认隐藏的 Tab 页里的图表容器在页面加载时宽度和高度都是 0。等用户切到那个 Tab图表显示出来了但此时如果触发了窗口 resize或者我用 ResizeObserver 监听容器可能拿到的是 0 尺寸ECharts 会根据 0 宽度 0 高度去计算布局结果画出来的东西完全不对甚至某些版本会报内部错误。排查这类问题建议在 init 和 resize 时都用getBoundingClientRect()检查一下容器的实际尺寸如果宽度或高度为 0 就跳过等容器真正变为可见尺寸后再画。function canResize(dom) { const rect dom.getBoundingClientRect() return rect.width 0 rect.height 0 } function safeResize(chart, dom) { if (!chart || chart.isDisposed()) return if (!canResize(dom)) return chart.resize() }如果是切换 Tab 的场景还有个更省事的方案不提前初始化图表等 Tab 真正显示出来、容器可见后再 init。这样既避免了 0 尺寸初始化的问题也能减少页面初始加载时的性能开销。唯一要注意的是初始化逻辑要设计成可重入避免 Tab 切换多次时重复生成实例。5. 常见问题与排查技巧实录5.1 问题速查表把我在项目里遇到过的 resize 相关报错整理成一张速查表遇到同类问题直接对照排查比自己从头看源码快得多。报错 / 现象根本原因快速解法Cannot read properties of undefined (reading type)resize 时图表实例已销毁或内部对象被清空resize 前用isDisposed()判空There is a chart instance already initialized on the dom同一 DOM 容器重复 initinit 前用getInstanceByDom()检查并 dispose图表不随窗口变化resize 监听没绑定成功或 this 指向错误用箭头函数/显式 bind 绑定监听组件销毁后控制台持续报错window 监听器未移除在销毁钩子里 removeEventListener 对应具名函数路由切换后回到页面图表空白容器可能被复用但实例已销毁在激活钩子里根据容器状态重新 init弹窗内图表关闭后再打开报错容器销毁但实例引用还在关闭弹窗时 dispose打开时重新 init图表显示尺寸为 0 的白色区域容器在 display:none 状态下初始化容器可见后再 init或 resize 前判断尺寸这张表里的每一行都是我实际碰过的真实场景。其中getInstanceByDom这个接口强烈建议记住它比手动维护实例引用的方案靠谱得多适合那种状态比较混乱、不知道谁在引用图表的兜底清理场景。5.2 三个实战排查经验经验一定位报错来源先在 window resize 回调里 console.log 所有图表实例。遇到Cannot read properties of undefined这类模糊报错第一反应不应该是去看 ECharts 源码而是确认当前到底有哪几个图表实例还挂着 resize 监听。我的做法是在全局 resize 监听回调开头临时打一行日志输出每个 chart 实例的isDisposed()状态和容器 DOM 的isConnected状态。状态异常的实例就是元凶。经验二在 dispose 前确认监听器能移除。很多人写了removeEventListener但没效果原因就是绑定时用了匿名函数移除时传了另一个函数两者引用不一致。排查时可以在绑定处打一个标记比如window.__resizeHandler handleResize然后在销毁钩子里console.log(window.__resizeHandler handleResize)来验证移除是否成功。如果为 false那 remove 的就不是同一个函数。经验三复杂项目直接用 echarts.getInstanceByDom 做兜底清理。有一次接手的项目里图表逻辑非常乱到处是 init。找到报错点之后我干脆写了一个全局清理工具遍历所有注册过的 DOM 节点对每个节点调用echarts.getInstanceByDom(dom)拿到实例就 dispose在报错出现前清光所有残留实例业务代码再重新走一遍初始化流程。这种暴力重置在排障时很好用能快速把问题范围缩小到某一处代码逻辑而不是纠结于已经乱掉的运行时状态。写在最后的个人体会处理完这次 resize 报错之后我最大的感触是ECharts 本身没那么多坑坑大多出在开发者对实例生命周期的管理上。init之后要把实例当做一个有生命的对象来对待从出生到销毁的每一步都要和页面容器、事件监听、框架生命周期严格对齐。我自己现在写图表组件已经把echarts.getInstanceByDom判空、isDisposed()判断、具名监听函数、销毁时先移除监听再 dispose 这四件事变成了肌肉记忆。数据可视化项目里图表越多这套规范带来的价值就越明显。如果你是刚被这个报错折磨完别烦躁把这篇里的管理方案拿过去改一改大概率能直接解决问题。