Chart.js 性能优化全解：从数据解析、抽稀算法到 Web Worker 并行渲染

Chart.js 基于 canvas 元素渲染图表，绘制本身相当快速，但在面对大规模数据集或对性能敏感的应用时，渲染耗时与内存占用仍可能成为瓶颈。本篇围绕 Chart.js 官方性能文档，系统讲解四大类优化手段——数据准备（解析关闭、归一化、抽稀）、刻度计算加速、动画与绘图元素裁剪，以及 Web Worker 并行渲染，并结合仓库源码逐条印证每项优化的底层实现，帮助你为大型图表构建一套可落地、可验证的性能调优方案。

一、数据结构与格式：把开销花在刀刃上

1.1 关闭解析（parsing）

默认情况下，Chart.js 会使用图表类型与坐标轴关联的解析器处理传入的 data。解析是每次更新都会重复的纯 CPU 开销。如果数据已经在外部准备成了图表与坐标轴接受的内部格式，可以直接关闭解析：

new Chart(ctx, {
  type: 'line',
  data: {
    datasets: [{
      data: [{x: 10, y: 20}, {x: 15, y: 30}, {x: 20, y: 10}],
      parsing: false
    }]
  }
});

关于内部格式的完整说明（Primitive[]、Array[]、Object[]、Object 等形态，以及 category 坐标轴内部使用整数索引等细节），参见 数据结构文档。核心规则是：关闭解析后，数据必须已排序，并且是关联图表类型和坐标轴内部使用的格式。例如 category 坐标轴内部以整数作为索引值（每个整数对应 labels 数组中的一个位置），若解析开启它可以接受字符串标签，而关闭后就必须传入内部格式。null 可用于表示跳过值。

1.2 数据归一化（normalized）

Chart.js 在数据索引唯一、有序，且在多个 dataset 之间保持一致时运行最快。此时可以通过 normalized: true 选项告知 Chart.js 数据已满足该前提，避免内部对索引做重复的归一化处理：

new Chart(ctx, {
  type: 'line',
  data: {
    datasets: [{
      data: [[0, 10], [1, 20], [2, 30]],  // x 唯一且升序
      normalized: true
    }]
  }
});

源码中这一选项的类型定义位于 src/types/index.d.ts，其注释与官方文档一致："Chart.js is fastest if you provide data with indices that are unique, sorted, and consistent across datasets and provide the normalized: true option to let Chart.js know that you have done so."

从源码结构看，time 坐标轴对归一化数据有专门的快速路径：src/scales/scale.time.js 中会读取 opts.normalized 并写入 this._normalized，随后在 scale.time.js#L637 与 scale.time.js#L664 中，当 _normalized 为真时直接使用原始 timestamps、跳过逐点 normalize 调用。也就是说，即使不显式开启该选项，提供已排序的数据本身有时也能更快。

1.3 抽稀（Decimation）：最有效的单项优化

当图表上有数万乃至数十万个点，而画布只有一两百像素宽时，逐个绘制完全没有意义——抽稀数据能取得最佳效果。

方案一：decimation 插件（推荐）

decimation 插件可在渲染前对 line 图数据做抽稀，由于直接减少了参与渲染的数据量，能同时降低内存占用与绘制成本，性能收益最大。

插件实现位于 src/plugins/plugin.decimation.js，关键行为可以从源码中确认：

• 两种算法：min-max（默认）与 lttb（Largest Triangle Three Buckets）。minMaxDecimation 按屏幕像素列分组，每组保留 min/max 点，保证极值不丢失（plugin.decimation.js#L82-L154）；lttbDecimation 则基于"最大三角形三桶"算法挑选最能代表曲线形态的样本点（plugin.decimation.js#L3-L80）。
• 阈值机制：threshold 默认为 4 * availableWidth，可见点数不超过阈值时不做抽稀（plugin.decimation.js#L242-L247）。
• 适用前提：仅支持 X 方向为索引轴的 line 数据集、仅支持 linear/time 类型的 x 轴、且要求 parsing 为假（plugin.decimation.js#L220-L239）。
• 无副作用：插件通过 Object.defineProperty 劫持 dataset.data 的 getter/setter，原始数据保存在 _data 上，dataset._decimated 保存抽稀结果；一旦禁用插件或销毁图表，会还原 data 属性、清理临时字段（plugin.decimation.js#L249-L264、cleanDecimatedData），原始数据不受破坏。

方案二：绘制期自动抽稀（Automatic decimation during draw）

line 元素在满足特定条件时会在绘制阶段自动跳过不可见线段，属于"零配置"优化。条件与代价在下文"line 图绘制细节"一节中展开。

需要注意的是：自动抽稀发生在图表生命周期的较后阶段（绘制时），因此官方建议为了获得最大性能，仍应自行在传入数据前完成抽稀——手动抽稀不仅省掉绘制，还省掉解析、数据限制计算等前序步骤。

二、刻度计算（Tick Calculation）优化

坐标轴的标签尺寸计算、旋转角度求解是更新流程中的主要开销之一，尤其是标签很多时。

2.1 固定旋转角度（Rotation）

将 minRotation 和 maxRotation 设置为相同值，可以避免 Chart.js 自动试探旋转角度：

options: {
  scales: {
    x: {
      ticks: {
        minRotation: 45,
        maxRotation: 45
      }
    }
  }
}

自动旋转的完整配置说明见 笛卡尔坐标轴文档的 tick 配置一节。源码中，calculateLabelRotation 是在 configure 之后被调用的（src/core/core.scale.js#L449-L454），它需要基于已测量的标签尺寸反复试探角度——固定旋转值后这条试探路径即可跳过。

2.2 标签采样（Sampling）

设置 ticks.sampleSize 选项，可以只测量标签的一个子集来估算标签尺寸，从而更快完成坐标轴布局；当各标签尺寸差异不大时效果最佳：

options: {
  scales: {
    x: {
      ticks: {
        sampleSize: 100
      }
    }
  }
}

实现位于 src/core/core.scale.js 的 update 流程中（core.scale.js#L393-L443）：

const sampleSize = tickOpts.sampleSize;
...
// Compute tick rotation and fit using a sampled subset of labels
// We generally don't need to compute the size of every single label for determining scale size
const samplingEnabled = sampleSize < this.ticks.length;
this._convertTicksToLabels(samplingEnabled ? sample(this.ticks, sampleSize) : this.ticks);

可见逻辑是：仅当 sampleSize < ticks.length 时才启用采样，从 this.ticks 中均匀抽取 sampleSize 个刻度去转换标签、测量尺寸；另外在 core.scale.js#L801-L804 处，标签数量超出 sampleSize 时同样会先做 sample 采样再渲染。也就是说，sampleSize 同时作用于"尺寸测量"与"标签渲染"两条路径。

三、关闭动画（Disable Animations）

如果图表渲染时间较长，关闭动画是立竿见影的手段：动画意味着一次更新要触发多帧渲染，关闭后一次更新只需渲染一次，直接降低 CPU 占用、改善整页性能。

new Chart(ctx, {
  type: 'line',
  data: data,
  options: {
    animation: false
  }
});

源码侧还有一个与动画相关的额外收益：line 图在动画禁用且 Path2D 可用时会使用 Path2D 缓存。src/elements/element.line.js 的 draw 函数中：

const usePath2D = typeof Path2D === 'function';

function draw(ctx, line, start, count) {
  if (usePath2D && !line.options.segment) {
    strokePathWithCache(ctx, line, start, count);
  } else {
    strokePathDirect(ctx, line, start, count);
  }
}

strokePathWithCache 会把整条线路径构建进 line._path（一个 Path2D 实例）并缓存，后续帧直接 ctx.stroke(path) 复用，避免每帧重新执行 beginPath/lineTo 序列。缓存路径的失效由元素自身的 dirty 机制管理，动画过程中的形变则走无缓存路径。

四、显式指定坐标轴的 min 和 max

若显式给出 min 与 max，坐标轴就无需从数据中计算范围：

new Chart(ctx, {
  type: 'line',
  data: data,
  options: {
    scales: {
      x: {
        type: 'time',
        min: new Date('2019-01-01').valueOf(),
        max: new Date('2019-12-31').valueOf()
      },
      y: {
        type: 'linear',
        min: 0,
        max: 100
      }
    }
  }
});

在 src/core/core.scale.js 的 update 流程中，determineDataLimits 负责从数据推算范围（core.scale.js#L424-L431），而 getUserBounds 返回的 minDefined/maxDefined 标志则标记了用户显式边界的存在（如 core.datasetController.js#L129-L132 中对已定义边界与非边界值的使用）。显式边界在多个环节生效：不仅跳过（或部分跳过）范围推断，还能让抽稀插件通过 getUserBounds 精确定位可见数据区间（plugin.decimation.js#L176-L195），减少参与抽稀计算的数据量。

五、Web Worker 并行渲染

自 2023 年起，现代浏览器支持把 canvas 的渲染控制权 transferControlToOffscreen 转移给 Web Worker，Worker 通过 OffscreenCanvas API 在独立线程上渲染 DOM 中的 canvas。Chart.js 是纯 canvas 库，天然支持这一模式——只需把 OffscreenCanvas 传给 Chart 构造函数，代替 Canvas 元素即可。

把所有 Chart.js 计算搬到独立线程后，主线程可被释放给其他用途。使用时的注意事项（官方建议）：

• 线程间传输数据开销大，config 与 data 对象应尽量小。能在工作线程内生成就在那里生成（worker 可以发 HTTP 请求！），否则尽量以 ArrayBuffer 形式传输——它们可以在线程间快速转移。
• 函数不能跨线程传输：config 对象中若含函数，转移前需剥离、到达后再补回。
• worker 线程无法访问 DOM：依赖 DOM 的 Chart.js 插件（包括一切鼠标交互）在 worker 中大概率不工作。
• 若需兼容旧浏览器，必须有回退方案。
• 图表缩放必须手动完成：OffscreenCanvas 没有事件监听器，示例见下文 worker 代码。

主线程示例代码：

const config = {};
const canvas = new HTMLCanvasElement();
const offscreenCanvas = canvas.transferControlToOffscreen();

const worker = new Worker('worker.js');
worker.postMessage({canvas: offscreenCanvas, config}, [offscreenCanvas]);

worker.js 中的示例代码：

onmessage = function(event) {
  const {canvas, config} = event.data;
  const chart = new Chart(canvas, config);

  // Resizing the chart must be done manually, since OffscreenCanvas does not include event listeners.
  canvas.width = 100;
  canvas.height = 100;
  chart.resize();
};

仓库自带一个可运行的最小 worker 示例 test/BasicChartWebWorker.js：它接收 { type: 'initialize', canvas } 消息后 new Chart(canvas)，并断言该 chart 使用的是 BasicPlatform（BasicChartWebWorker.js#L18-L21）——这印证了从源码结构看，Chart.js 在非 DOM 环境（worker）下会自动退化到基础平台，DOM 相关能力（如 platform.dom.js 提供的原生事件绑定）不参与工作，与上面"插件与交互不可用"的结论一致。

六、line 图绘制细节

6.1 保持贝塞尔曲线关闭

绘制直线比绘制贝塞尔曲线开销更低，tension 默认为 0（即关闭曲线），建议保持默认。src/elements/element.line.js#L250-L262 中 LineElement.defaults 定义了 tension: 0、stepped: false、borderDash: [] 等默认值。

6.2 绘制期自动数据抽稀

line 元素会在 tension、stepped、borderDash 均保持默认值（false、0、[]）时自动抽稀数据，其原理是跳过绘制不可见的线段（同一像素列内多个点只会画一次垂直方向）。

这一条件在源码中一目了然，即 src/elements/element.line.js#L185-L190 的快速路径判定：

function _getSegmentMethod(line) {
  const opts = line.options;
  const borderDash = opts.borderDash && opts.borderDash.length;
  const useFastPath = !line._decimated && !line._loop && !opts.tension
    && opts.cubicInterpolationMode !== 'monotone' && !opts.stepped && !borderDash;
  return useFastPath ? fastPathSegment : pathSegment;
}

满足条件时走 fastPathSegment（element.line.js#L127-L178），它按截断后的整数 x 坐标分组，同一 x 列只记录 min/max y，从而跳过同列内的重复绘制；否则退回通用的 pathSegment。另外注意第一个条件 !line._decimated：当 decimation 插件已对数据做过抽稀时（controller.line.js#L59 会把 dataset._decimated 透传到 line 元素），快速路径自动关闭——两者不会叠加冲突。

6.3 启用 spanGaps

数据点很多时，开启 spanGaps 可能更快：它禁用 line 的分段（segmentation），省去一次可能不必要的步骤。

new Chart(ctx, {
  type: 'line',
  data: {
    datasets: [{
      spanGaps: true // enable for a single dataset
    }]
  },
  options: {
    spanGaps: true // enable for all datasets
  }
});

从 src/elements/element.line.js#L235-L241 可见，line.options.segment 为真时连 Path2D 缓存都会关闭，因此"分段"是 line 绘制中一条成本明显更高的路径，spanGaps 同时影响性能与 Path2D 缓存可用性。

6.4 禁用 line 绘制

数据点很多时，可以禁用某个 dataset 的折线、只画点，减少画布上的绘制内容：

new Chart(ctx, {
  type: 'line',
  data: {
    datasets: [{
      showLine: false // disable for a single dataset
    }]
  },
  options: {
    showLine: false // disable for all datasets
  }
});

6.5 禁用 point 绘制

反之也可以只画线、不画点。注意这里的配置粒度有三种：单 dataset（pointRadius: 0）、所有 line dataset（options.datasets.line.pointRadius: 0）、全局所有元素（options.elements.point.radius: 0）：

new Chart(ctx, {
  type: 'line',
  data: {
    datasets: [{
      pointRadius: 0 // disable for a single dataset
    }]
  },
  options: {
    datasets: {
      line: {
        pointRadius: 0 // disable for all `'line'` datasets
      }
    },
    elements: {
      point: {
        radius: 0 // default to disabled in all datasets
      }
    }
  }
});

七、Babel 转译：使用 loose 模式

若项目通过 Babel 转译，建议使用 loose 模式。Babel 7.9 改变了 class 的构造方式，默认严格模式下的类构造较慢，配合 loose 模式可避免这部分运行时代价（详见 Babel 官方 issue #11356 的讨论）。这属于构建链层面的优化，建议在 @babel/preset-env 或相关插件配置中开启 loose: true 后验证产物行为是否符合预期。

八、优化清单小结

优化项	配置/操作	适用场景	源码依据
关闭解析	parsing: false	数据已按内部格式准备	docs/general/data-structures.md
数据归一化	normalized: true	索引唯一、有序且跨 dataset 一致	src/scales/scale.time.js#L287
数据抽稀	decimation 插件（min-max/lttb）	大数据量 line 图	src/plugins/plugin.decimation.js
固定刻度旋转	minRotation = maxRotation	标签很多	src/core/core.scale.js#L452-L454
标签采样	ticks.sampleSize	标签尺寸差异小	src/core/core.scale.js#L442-L443
关闭动画	animation: false	渲染耗时长；启用 Path2D 缓存	src/elements/element.line.js#L207-L241
指定 min/max	scales 显式边界	范围已知	src/core/core.scale.js#L424-L431
Web Worker 渲染	transferControlToOffscreen + OffscreenCanvas	计算密集、主线程繁忙	test/BasicChartWebWorker.js
关闭贝塞尔/步进/虚线	保持 tension: 0、stepped: false、borderDash: []	触发快速绘制路径	src/elements/element.line.js#L188
spanGaps	spanGaps: true	点多、可省去分段与保留 Path2D 缓存	src/elements/element.line.js#L236
只画线或只画点	showLine: false / pointRadius: 0	点数极大	—

落地建议遵循官方文档的主次顺序：先做数据层面的工作（准备内部格式、排序、抽稀），这是收益最大且一劳永逸的部分；再做坐标轴与动画层面的配置（sampleSize、固定旋转、min/max、关闭动画）；最后针对 line 图启用快速绘制路径，或在计算量极大时把整个图表迁入 Web Worker。每一层优化都可独立验证：先测量更新耗时与帧率，再逐项开启，即可定位对自己数据特征最有效的手段。