D3.js 7 的 Observable Plot：高层抽象让数据可视化更简单

从 D3 说起：强大的代价是什么

如果你写过一段时间的 D3，大概会有这么一种感觉：它是一把非常锋利的手术刀，但你要自己学会怎么握。从 d3.scaleLinear 到 d3.forceSimulation，每一个模块都像是乐高零件，能拼出任何东西，但没有任何一套固定的组合方式。很多时候只想画一个柱状图，却要手动处理比例尺、坐标轴、分组、过渡，代码写了几十行，并且这些代码很难在下一个项目里复用。

D3.js 7 发布之后，Observable 团队把很多精力放在了 Observable Plot 上。它是一个基于 D3 的高层可视化库，目标恰好是解决上面这种“杀鸡用牛刀”的问题。这篇文章我想从工程角度聊聊 Plot 带来的变化、它和 D3 之间的关系，以及在实际项目里应该怎么选型。

Observable Plot：声明式图表的另一种答案

Plot 的设计思路很简单：你告诉它数据是什么、要画哪种图形，它负责剩下的一切。它把常见的可视化类型拆分成一组“标记”（marks），比如柱状图、折线、散点、密度图、区域图等。一个最基本的柱状图可以写成这样：

const chart = Plot.plot({
  marks: [
    Plot.barY(data, { x: 'year', y: 'value' })
  ]
});
document.body.appendChild(chart);

如果换成 D3 直接写，光是比例尺和坐标轴就要不少代码：

const svg = d3.select('body')
  .append('svg')
  .attr('width', width)
  .attr('height', height);

const x = d3.scaleBand()
  .domain(data.map(d => d.year))
  .range([margin.left, width - margin.right])
  .padding(0.1);

const y = d3.scaleLinear()
  .domain([0, d3.max(data, d => d.value)])
  .nice()
  .range([height - margin.bottom, margin.top]);

svg.append('g')
  .selectAll('rect')
  .data(data)
  .join('rect')
  .attr('x', d => x(d.year))
  .attr('y', d => y(d.value))
  .attr('width', x.bandwidth())
  .attr('height', d => y(0) - y(d.value));

svg.append('g')
  .attr('transform', `translate(0,${height - margin.bottom})`)
  .call(d3.axisBottom(x));

对比非常明显。Plot 把坐标轴、比例尺、文本标签都封装成了默认行为，而 D3 需要你显式地完成每一步。尤其当图表变得复杂时，这种差异会越来越大。

为什么说 Plot 更适合大多数业务场景？

Plot 最大的价值，是把“创建图表”这件事从工程任务变成了声明式描述。你不需要关心比例尺怎么配置、坐标轴怎么生成、图例放在哪，因为这些已经被封装成了合理的默认值。更重要的是，Plot 内置了一批数据转换方法，比如分组、分箱、聚合，这些在探索性分析中非常常用。

举个例子，你想按年份求和，然后画一个条形图，用 Plot 可以这样：

Plot.plot({
  marks: [
    Plot.barY(data, Plot.groupX({ y: 'sum' }, { x: 'year', y: 'value' }))
  ]
})

Plot 在处理大数据集时也有自己的策略。它通过通道（channel）来声明数据映射，例如颜色、尺寸、透明度都可以绑定到不同的数据字段。这种一致的设计让多个标记之间很容易组合成复杂的图形。比如我可以把柱状图和折线画在同一个坐标系里，因为它们的比例尺是自动共享的。另外，Plot 还支持分面（facet）——根据某个维度把图表拆分成多个小图，这在 D3 中需要自己实现。

Plot 不是替代 D3，而是 D3 的一种友好封装

很多初学者会问：有了 Plot，还需要学 D3 吗？我的观点是，Plot 并不能完全替代 D3。Plot 本身是基于 D3 构建的，它的内部使用了许多 D3 模块来支持比例尺、数学计算和布局。但对于使用者来说，确实可以暂时不用关心这些底层细节。

不过在两类场景下，Plot 会显得不够用。第一类是高度定制的图表，比如你需要把图形元素和业务领域模型深度绑定，例如地图上的飞线动画、自定义的力导向节点、复杂的交互动画。第二类是性能敏感的实时数据流，虽然 Plot 也做了很多优化，但如果你需要精确控制渲染过程和增量更新，直接用 D3 的 selection 和 transition 会更顺手。

三种方案对比：D3、Observable Plot、通用图表库

我把 D3、Observable Plot 和常见的通用图表库（比如 ECharts、Chart.js）放在一起做了个对比，方便你在选型时有个参考。

使用 Plot 时容易踩的坑

在实际使用中，我遇到这些问题比较常见：

• 误区一：试图用 Plot 替换所有 D3 代码。如果你的项目里已经有大量 D3 定制图表，全部重写没有意义，反而可能遇到 Plot 没有提供“后门”的边缘情况。更务实的做法是：新图表用 Plot，老代码不动。
• 误区二：不看源码。Plot 的文档很精简，很多细节藏在源码里。比如某些标记的默认通道类型、缩放逻辑，不查源码很难理解边界行为。遇到疑问直接去看 Observable Plot 的源码仓库，它仍然是 D3 生态，很多经验可以复用。
• 误区三：追求“纯声明式，零代码”。Plot 能省代码，但它不是数据清洗银弹。复杂的数据预处理还是要放在前置阶段，把数据结构整理好，否则把逻辑塞进通道函数里，调试会很痛苦。

什么情况下值得用 Plot？

根据我接触过的项目，以下场景特别适合引入 Plot：

• 探索性数据分析：在 Notebook 里快速理解数据分布、趋势和相关性。
• 内部工具和监控面板：图表类型固定，不追求炫酷视觉，重点是快速输出和可维护性。
• 作为 D3 项目的“预处理层”：先用 Plot 验证数据和可视化方案，再决定要不要用 D3 做定制。

如果你要做的报告或产品需要高度品牌化的视觉呈现，或者图表会与页面其他部分产生复杂的联动交互，我建议还是优先考虑 D3，并且配合 React 这样的框架管理状态。Plot 在这些场景下可能成为限制，因为它的抽象层会阻挡你对 DOM 细节的控制。

举一个常见的例子。一个数据团队要做一个周报系统，里面的图表无非是折线图、柱状图、散点图。用 ECharts 虽然也能快速实现，但当数据格式变化时，要反复和配置项战斗；用 Plot 可以直接把数据传进去，它的 scale 会根据数据的 domain 自动更新，维护成本低很多。但后来他们需要增加一个桑基图，而 Plot 没有这个标记，于是最终选择了在同一个系统中混合使用 Plot 和 D3——标准图表用 Plot，复杂图表用 D3 写成一个可复用的组件。

如何让 Plot 和 D3 协作

Plot 的 plot.plot 返回的是标准 HTML 或 SVG 元素，你可以像操作普通 DOM 一样把它插入容器，再用 D3 的 selection 来操作它。比如你可以在 Plot 生成的 SVG 上继续追加元素，或者添加自定义事件。

const chart = Plot.plot({
  marks: [
    Plot.line(data, { x: 'date', y: 'value' })
  ]
});

d3.select(chart)
  .append('circle')
  .attr('cx', 200)
  .attr('cy', 100)
  .attr('r', 5);

这种组合方式在实际项目里很灵活。plot.plot 还提供了一些配置项，比如 x: { tickFormat: ... } 来定制坐标轴刻度格式；如果仍不满足，你可以通过自定义标记函数进一步接入 D3 的底层逻辑。

从 D3 到 Plot：我的选型经验

最后分享一下我的个人判断。如果你的需求是“常见图表 + 数据探索 + 不想花太多时间维护图表代码”，Plot 是很好的选择。它比 ECharts 更加数据驱动，比 D3 原生开发更省时间。如果你需要深度定制，那么 D3 仍然是不二之选。两者不是对立关系，而是一种分工：Plot 负责“快”，D3 负责“深”。

D3 7 之后，生态里能有一个这样善解人意的高层抽象，是一件值得开心的事。它降低了可视化入门的门槛，却又保留了向上探索的路径。即使在真实项目中，它也会有边界，但清晰边界本身就是好的设计。