ECharts 大数据量渲染自救：降采样、按需引入与主题定制工程化实录

监控大屏首屏 9 秒、折线图塞进三十万个监控点后拖动 dataZoom 直接卡死、暗色主题在每个图表里各写一份配色导致改一次要动二十处——这是接手可视化模块时面临的三座大山。它们分别对应 ECharts 工程化的三个课题：体积、性能、一致性。本文把这三座山的治理过程完整记录下来，代码均可直接运行。

体积治理：按需引入，别把整个 ECharts 打进包

全量引入 import * as echarts from "echarts" 会把所有图表类型、组件、渲染器都打进构建产物，首屏加载为用不到的能力买单。ECharts 5 起官方支持按需注册，从 echarts/core 引入核心，再显式注册项目里实际用到的部分：

// src/lib/echarts.ts：全项目唯一的 ECharts 入口，按需注册
import * as echarts from "echarts/core";
import { LineChart, BarChart, PieChart } from "echarts/charts";
import {
  GridComponent, TooltipComponent, DataZoomComponent, LegendComponent
} from "echarts/components";
import { CanvasRenderer } from "echarts/renderers";

// 只注册项目实际用到的图表与组件，构建体积显著下降
echarts.use([
  LineChart, BarChart, PieChart,
  GridComponent, TooltipComponent, DataZoomComponent, LegendComponent,
  CanvasRenderer
]);

export default echarts;

业务侧统一从这个文件导入 echarts，注册收口在一处，新增图表类型只改这一个文件。这个改造通常能把可视化相关构建产物压缩到原来的三分之一左右，具体比例取决于用到的能力范围——柱状图加折线图的典型面板收益最明显。

性能治理：大数据量的三层降级策略

几十万点的折线为什么卡？每一帧交互都要处理全部数据点。治理按「渲染层 → 序列层 → 业务层」三层层层设防：

渲染层：启用渐进渲染，让 ECharts 分批处理数据，避免一次性巨帧：

const option = {
  series: [{
    type: "line",
    sampling: "lttb",    // LTTB 抽稀：保留视觉趋势的关键拐点，肉眼几乎无差别
    progressive: 2000,   // 每批 2000 点渐进渲染，交互不再长阻塞
    large: true,         // 海量散点/柱状开启 large 模式，走优化绘制路径
    symbol: "none",      // 数据点密集时隐藏标记点，减少绘制对象
    data: points
  }]
};

sampling: "lttb" 是性价比最高的一档：LTTB（Largest-Triangle-Three-Buckets）抽稀在大幅减少点数的同时保留波峰波谷形状，比简单等距采样保真得多，密集曲线的视觉趋势基本不失真。

序列层：交互期动态降载。dataZoom 拖动过程中，用 dataZoom 事件回调把数据临时切到更粗的聚合粒度，拖动结束再加载精细数据——用户感知到的是「拖动流畅 + 松手变精细」。

业务层：原始数据不下发。三十万点数据量本身就有几百 KB 到 MB 级，传输和解析都是负担；服务端按可视粒度预聚合（如按分钟均值），前端 dataZoom 变化范围超出当前数据粒度时，按需拉取对应区间的聚合数据。这一层做完，前端任何时刻处理的数据都在万点以内，前面两层更多是保底。

三层的投入顺序也有讲究：先上 sampling 与 progressive 这类一行配置的渲染层手段，用 Performance 面板验证效果——优化前拖动 dataZoom 能看到几百毫秒的长任务块，优化后长任务应当消失或碎成 16ms 级的小片；如果渲染层手段之后仍有肉眼可见的卡顿，再投入业务层预聚合的改造成本，因为它要动服务端接口，是三层里最贵的。验证指标就用 dataZoom 拖动时的交互帧率与 setOption 耗时，肉眼流畅度是最终标准，数字只是辅助证据。

主题定制：从设计 token 到 registerTheme

主题散落是可视化项目的慢性病：每个图表组件里各写一份颜色、圆角、字体，设计规范一改就是全项目大扫除。解法是把设计稿的颜色、字体、间距提炼成 token，一次性注册成 ECharts 主题：

// 主题注册一次，全项目复用；改设计规范只动这一个文件
echarts.registerTheme("app-dark", {
  color: ["#5B8FF9", "#5AD8A6", "#F6BD16", "#E8684A", "#6DC8EC"],
  backgroundColor: "transparent",           // 背景交给页面容器，图表自身透明
  textStyle: { fontFamily: "Inter, sans-serif" },
  legend: { textStyle: { color: "#8CA0B3" } },
  categoryAxis: { axisLine: { lineStyle: { color: "#2A3B4D" } } }
});

// 初始化时挂主题
echarts.init(el, "app-dark");

原则是「主题放视觉、业务放语义」：主题里只放全局视觉规范，告警红、状态色这类业务语义用 series 级样式覆盖，避免主题文件膨胀成业务配置的垃圾场。多主题需求（亮色管理后台 + 暗色大屏）就是多注册几套主题，切换时重建实例即可。

生命周期封装：resize 与 dispose 的统一管理

ECharts 实例不会自己感知容器变化，也不会自己销毁——这两件事漏了哪件，长期运行的大屏都会出问题（布局变了图不跟，路由切多了内存涨）。用组合式函数统一收口：

// composables/useEcharts.ts：实例生命周期统一管理
import * as echarts from "@/lib/echarts";
import { onMounted, onBeforeUnmount, type Ref } from "vue";

export function useEcharts(el: Ref<HTMLElement | null>) {
  let chart: echarts.ECharts | null = null;
  const ro = new ResizeObserver(() => chart?.resize()); // 容器尺寸变化自动重绘

  onMounted(() => {
    if (el.value) {
      chart = echarts.init(el.value, "app-dark");
      ro.observe(el.value);
    }
  });

  onBeforeUnmount(() => {
    ro.disconnect();
    chart?.dispose();      // 离开页面必须销毁，否则实例与 canvas 泄漏
    chart = null;
  });

  return { setOption: (opt: echarts.EChartsCoreOption) => chart?.setOption(opt) };
}

这个封装让业务组件只关心数据与配置，实例管理、主题、销毁全部内聚，也顺便解决了「resize 不跟随」和「路由切换内存泄漏」两个最高频问题。

避坑总结

resize 不会自动发生。侧边栏折叠、窗口调整、Tab 切换后图表尺寸错位，根源都是没人调 resize；容器级监听用 ResizeObserver，比 window.resize 覆盖面广得多。
dispose 缺失是可视化页面的头号内存泄漏源。监控大屏这类常驻页面症状不明显，路由频繁切换的管理后台几分钟就能观察到内存持续上涨；封装层统一销毁，别依赖每个业务组件自觉。
tooltip 的 formatter 别做重活。十万点场景下自定义 formatter 里遍历数据、拼字符串会把 hover 拖成卡顿；能用 valueFormatter 就别用全量 formatter，必须复杂处理时先缓存计算结果。
渲染器选择别一刀切。canvas 是大数据量的默认选择；导出高清图、点数少且需要无级缩放的图（流程图、关系图）才考虑 SVG，SVG 在大数据量下节点开销会反噬性能。
数据更新用 notMerge 要清醒。setOption(option, true) 全量替换会丢掉用户当前的缩放状态；联动场景默认增量合并，确需重置时显式恢复 dataZoom 的 start/end，别让用户莫名其妙回到全量视图。

写在最后

ECharts 工程化的三件事——体积、性能、一致性——对应的工程动作是按需注册、分层降级、主题收口。单独看每一件都不复杂，难的是团队约定：渲染入口收口、实例生命周期统一、主题只放视觉规范，这些约定一旦松动，三座大山就会重新长回来。把约定固化在 useEcharts 这样的基础设施层，才是可视化模块能长期维护的根本。

免责声明

本工具与文章内容仅用于学习测试场景，优化建议仅供参考，请勿直接用于生产环境，由此产生的风险自行承担。

ECharts 大数据量渲染自救：降采样、按需引入与主题定制工程化实录 ​

体积治理：按需引入，别把整个 ECharts 打进包 ​

性能治理：大数据量的三层降级策略 ​

主题定制：从设计 token 到 registerTheme ​

生命周期封装：resize 与 dispose 的统一管理 ​

避坑总结 ​

写在最后 ​