ECharts 5 的按需引入与性能优化：大数据量渲染的正确配置

很多项目接 ECharts 的时候，都是从全量引入开始的。引用简单，一个 import 就能用所有图表，开发效率也高。但等到项目要收敛体积，或者数据量堆到一定量级，问题就会浮现出来。我见过不少团队，明明只是做一个后台报表，却把整个 ECharts 打进了首屏包；也见过监控大屏渲染两万多个点之后，交互明显迟滞。这两个问题其实不在同一个层面，前者是模块组织的问题，后者是渲染机制的问题，但它们经常一起出现。

这篇文章想聊清楚两件事：ECharts 5 的按需引入应该怎么做，以及面对大数据量渲染，哪些配置项是真正有用的。顺便会拆几个常见误区，免得后续排查的时候走弯路。

按需引入：省下的不只是包体积

ECharts 5 在架构上做了一次明显的拆分。现在的包入口更像一个依赖注入容器，核心在 echarts/core 里，图表、组件、渲染器都变成独立模块。你用什么，就注册什么。这种设计的直接收益是 tree-shaking 能真正生效，打包后只保留被注册的代码。

很多团队知道要按需引入，但实际写法还是有问题。最常见的是从 echarts 入口引入图表或组件，再传给 echarts.use。这样做并不会让 tree-shaking 生效，因为你已经引用了完整的包。正确的姿势是从对应的子路径导入。

import * as echarts from 'echarts/core';
import { LineChart } from 'echarts/charts';
import { GridComponent, TooltipComponent } from 'echarts/components';
import { CanvasRenderer } from 'echarts/renderers';

echarts.use([LineChart, GridComponent, TooltipComponent, CanvasRenderer]);

这段代码的意思很直白：核心容器、折线图、网格和 tooltip 组件、Canvas 渲染器，都注册好之后，init 出来的实例就能正常画折线图了。如果用的渲染方式是 SVG，就把 CanvasRenderer 换成 SVGRenderer。需要注意的是，echarts/core 本身不包含任何图表的默认支持，所以漏掉一个组件，最常见的问题就是图表预览一片空白，但控制台没错误。

这里有个容易被忽略的细节。按需引入不只是为了减少打包体积，它也在约束依赖关系。全量包里有很多组件之间的隐藏耦合，而显式注册能让你更清楚当前项目到底依赖什么。尤其是团队里后续接手的人，看到一个十几行的 use 注册列表，比翻 package.json 猜体积要直观得多。

大数据量渲染：先选对渲染器

数据量上来之后，第一个要检查的是渲染器。ECharts 默认使用 Canvas，但也支持 SVG。不少人有一个印象，觉得 SVG 比 Canvas 性能好，其实不准确。

Canvas 是用一段连续的画布绘制所有图形，图形数量增加时，重绘代价会变大，但不会像 DOM 那样线性增加内存节点。SVG 的每个图形元素都会成为一个真实 DOM 节点，几千个节点浏览器还能应付，几万个节点就开始吃力，而且交互命中检测和重排成本会非常明显。对于大数据量，Canvas 是更稳的选择。

SVG 也有它的场景。比如数据量小、需要保留清晰的 DOM 结构用于导出或者测试，或者希望样式能自由被外部 CSS 控制，SVG 会更好用。这个判断完全可以量化，而不是拍脑袋。

采样与渐进渲染：大数据量图表的两大核心配置

数据量到了万级，单纯把 Canvas 渲染器打开还不够，因为要绘制的图形数量仍然很大。ECharts 提供了两个重要的机制：sampling 和 progressive。

sampling 是降采样，它在绘制之前对原始数据做一次抽取。这里不会随机丢点，而是尽量保留视觉上的趋势和峰值。折线图中比较推荐 sampling: 'lttb'，它专门用来做这种保留形态的降采样。如果只是简单配置 sampling: 'max' 或 'min'，适合用在高频数据中找边界极值，但整体形状容易被忽略。从大数据量图表配置的角度，更常用的还是 lttb。

progressive 是渐进渲染。它的思路是把渲染过程分成多个批次，先快速画出前一批，让用户看到图表正在出现，然后继续渲染后续批次。这样虽然总时间没有缩短，但避免了长时间阻塞主线程，页面不会表现为假死。配置时只需要在 series 里加上 progressive: 2000 表示每批渲染 2000 个点，实际上 ECharts 还有一层内置的判断，当数据量小于某个阈值时不会启用渐进。

option = {
  xAxis: { type: 'category' },
  yAxis: { type: 'value' },
  series: [{
    type: 'line',
    data: largeData,
    sampling: 'lttb',
    progressive: 2000,
    animation: false
  }]
};

这段配置里，animation: false 的意思很明确：大数据量下动画会带来额外的连续重绘，反而让用户感觉更卡。小数据量可以保留动画，数据量达到数万再使用动画，几乎没有任何正向体验，只会拉高 CPU 占用。

经验提醒：如果你的折线图数据量超过两万，并且还有缩放、拖拽这类交互，建议在 setOption 之后再触发一次 chart.resize() 或者重新设置 dataZoom，避免图表内部在处理完采样和渐进渲染之后留下失效的交互状态。

散点图与实时数据：large 模式和增量更新

折线图和散点图在大数据量下的配置思路不完全一样。散点图如果要展示的是数万甚至数十万个点，ECharts 提供了 large: true 模式。开启后，图表走一条专门的高性能渲染通道，开发者的操作空间变小，比如无法精确控制每个点的样式变化，但换来的是数量级上的流畅度提升。如果你关心的是整体分布，而不是每个点的具体属性，large 模式非常值得尝试。

实时数据场景还有一个容易踩的坑：每次有数据更新，就重新构造 option 并调用 setOption。这样做的代价是 ECharts 需要对新旧数据做 diff，数据量大的时候区别尤其明显。更好的方式是在初始化之后，使用 chart.appendData 增量追加数据，或者至少手动标记和替换数据数组，减少 diff 的成本。

不过 appendData 不是所有图表类型都支持，而且往往需要结合 large 模式使用。真正落地的判断标准，还是得回到数据量和更新频率上。如果每次只是追加几十个点，setOption 完全够用。

常见误区与排查思路

在项目现场最容易遇到的几个误区，我列一下，方便对照排查。

• 误区一：按需引入之后，还是从 echarts 入口导入图表。 这样 tree-shaking 不会生效，体积自然降不下去。
• 误区二：sampling 会让数据失真。 降采样确实改变了原始数据，但它的目标是视觉保真，在不影响趋势判断的前提下减少绘制量。真正对数据精度有要求的场景，应该考虑服务端聚合。
• 误区三：开了 progressive 就能解决一切。 渐进渲染只是避免主线程长时间阻塞，如果单个点的绘制代价本身就很高，光靠 progressive 不够，还需要配合采样或 large。
• 误区四：一个页面创建几十个图表实例没问题。 每个实例都有独立的定时任务和渲染管线，大屏场景下建议控制实例数量，或者用图表池统一管理，避免高频刷新时互相争抢主线程。

排查性能问题时，不要一上来就怀疑 ECharts。先用 Chrome Performance 录一段操作，看看是脚本执行时间高，还是渲染时间高。如果是脚本执行，再定位是 build 出来的 ECharts 代码太多，还是业务逻辑里反复 diff 数据。只有确认瓶颈在图上，再针对图表配置做优化。

不同数据规模下的推荐配置

为了更直观地做决策，我把常见的几种数据规模对应的配置方式整理成一张表。

这张表不是绝对标准，但它可以作为优化的起点。真实项目里，数据分布和交互复杂度都会影响临界点，还是以实际测量为准。

落地建议：按顺序做这三步

如果你的项目已经出现了 ECharts 相关的体积或性能问题，我建议按这个顺序来调整。

1. 先做按需引入。把 import 路径修到 echarts/core、charts、components、renderers，注册当前页面真正用到的模块。这一步收益稳定，且不影响功能。
2. 再确认渲染器。如果用的是 SVG，优先换回 Canvas；如果本来就是 Canvas，跳过。
3. 最后针对已有的大数据量图表，逐个加 sampling、progressive、关闭动画。每次只改一个配置，用浏览器性能面板对比前后变化。

ECharts 5 的性能优化，本质上不是在堆配置项，而是理解每个配置背后的代价。按需引入减少的是静态资源体积，采样减少的是绘制工作量，渐进渲染优化的是主线程时间片，large 模式则是用一种更贴近 canvas 本性的方式来换取吞吐量。想清楚这些，你自然知道什么场景该用什么配置。