D3.js是数据驱动文档的代表库，React则是声明式渲染的标杆，两者结合做可视化时，最经典的矛盾点在于：D3习惯直接操作真实DOM，而React要求通过虚拟DOM统一管理界面更新。如果处理不好这层关系，轻则出现图表渲染错乱，重则内存泄漏、组件卸载后动画还在跑。这篇文章就来系统地聊一聊两者如何分工协作，以及几种主流的集成方案各自适合什么场景。
先弄清楚冲突点：数据绑定与虚拟DOM的博弈
D3的核心思想是数据绑定（data join），通过selection.data()把数据数组关联到DOM元素上，然后用enter()、update()、exit()三个集合描述数据的增删改。这套机制的前提是D3拥有对DOM的直接控制权，它可以自己决定什么时候创建元素、删除元素、更新属性。
React的逻辑则完全相反。你只负责描述界面应该长什么样，React负责diff虚拟DOM并把变更应用到真实DOM上。如果D3在React不知情的情况下创建了元素，React在re-render时可能直接把这些元素当成“不该存在的东西”删掉；反过来，React更新了某个属性，D3缓存的选择器引用也可能失效。理解了这个根本矛盾，后面所有方案其实都是在回答一个问题：渲染的主控权交给谁。
实践中一般有三种答案：完全交给React（D3只当计算库用）、完全交给D3（React只提供容器）、以及按职责拆分（结构交给React、动画和交互交给D3）。下面逐一展开。
方案一：D3只做数学计算，React负责全部渲染
这是最容易维护的一种方式。D3强大的地方其实不只是操作DOM，它的比例尺、布局算法、形状生成器、插值函数都是纯函数，可以直接拿来算出SVG路径字符串，然后交给React去渲染。这样整个组件保持纯声明式，数据变化时React自动更新，不需要手动管理生命周期。
下面是一个折线图组件的完整示例，D3负责计算坐标和路径，React负责画：
import React, { useMemo } from 'react';
import * as d3 from 'd3';
function LineChart({ data, width = 600, height = 300 }) {
const margin = { top: 20, right: 30, bottom: 30, left: 40 };
// 所有D3计算都放在useMemo里，数据不变就不重复计算
const { linePath, xTicks, yTicks, scaleX, scaleY } = useMemo(() => {
const innerW = width - margin.left - margin.right;
const innerH = height - margin.top - margin.bottom;
const scaleX = d3.scaleLinear()
.domain([0, data.length - 1])
.range([0, innerW]);
const scaleY = d3.scaleLinear()
.domain([0, d3.max(data)])
.range([innerH, 0]);
// line生成器只输出路径字符串，不碰DOM
const linePath = d3.line()
.x((d, i) => scaleX(i))
.y(d => scaleY(d))
.curve(d3.curveMonotoneX)(data);
return {
linePath,
xTicks: scaleX.ticks(5),
yTicks: scaleY.ticks(4),
scaleX,
scaleY
};
}, [data, width, height]);
return (
<svg width={width} height={height}>
<g transform={`translate(${margin.left},${margin.top})`}>
{/* y轴网格线与刻度 */}
{yTicks.map(t => (
<g key={t} transform={`translate(0,${scaleY(t)})`}>
<line x2={width - margin.left - margin.right} stroke="#eee" />
<text x={-8} dy="0.32em" textAnchor="end" fontSize={12}>{t}</text>
</g>
))}
{/* x轴刻度 */}
{xTicks.map(t => (
<text key={t} x={scaleX(t)} y={height - margin.top - margin.bottom + 20}
textAnchor="middle" fontSize={12}>{t}</text>
))}
<path d={linePath} fill="none" stroke="#4a90d9" strokeWidth={2} />
</g>
</svg>
);
}这种方案的优点非常明显：代码完全符合React的思维模型，没有命令式的DOM操作，测试和调试都简单，多人协作时代码评审也轻松。缺点是D3的过渡动画体系用不上——d3.transition依赖对DOM的持续操作，与React的渲染节奏天然冲突，想加动画只能用CSS动画或者引入react-spring之类的库来补。
方案二：React只提供容器，D3全权接管DOM
当你确实需要D3的动画、拖拽、缩放这些交互能力时，可以把一块区域“划给”D3，让React只负责挂载一个容器元素，其余的事一概不管。这种模式下要用useRef拿到真实DOM节点，用useEffect初始化D3图表，并在数据变化时手动调用更新逻辑。
关键点在于必须区分“初始化”和“更新”两个阶段，否则每次re-render都会重复构建整张图。下面是力导向图的典型写法：
import React, { useRef, useEffect } from 'react';
import * as d3 from 'd3';
function ForceGraph({ nodes, links }) {
const svgRef = useRef(null);
useEffect(() => {
const svg = d3.select(svgRef.current);
svg.selectAll('*').remove(); // 清空重画，避免叠加
const width = 600, height = 400;
const simNodes = nodes.map(n => ({ ...n }));
const simLinks = links.map(l => ({ ...l }));
const simulation = d3.forceSimulation(simNodes)
.force('link', d3.forceLink(simLinks).id(d => d.id).distance(80))
.force('charge', d3.forceManyBody().strength(-120))
.force('center', d3.forceCenter(width / 2, height / 2));
const link = svg.append('g')
.selectAll('line')
.data(simLinks)
.join('line')
.attr('stroke', '#999');
const node = svg.append('g')
.selectAll('circle')
.data(simNodes)
.join('circle')
.attr('r', 8)
.attr('fill', '#4a90d9')
.call(d3.drag()
.on('start', (e, d) => {
if (!e.active) simulation.alphaTarget(0.3).restart();
d.fx = d.x; d.fy = d.y;
})
.on('drag', (e, d) => { d.fx = e.x; d.fy = e.y; })
.on('end', (e, d) => {
if (!e.active) simulation.alphaTarget(0);
d.fx = null; d.fy = null;
}));
simulation.on('tick', () => {
link.attr('x1', d => d.source.x).attr('y1', d => d.source.y)
.attr('x2', d => d.target.x).attr('y2', d => d.target.y);
node.attr('cx', d => d.x).attr('cy', d => d.y);
});
// 关键：组件卸载时必须停止仿真，否则定时器一直占用内存
return () => simulation.stop();
}, [nodes, links]);
return <svg ref={svgRef} width={600} height={400} />;
}这个方案能发挥D3的全部能力，复杂的交互和流畅的过渡动画都不在话下。代价是你放弃了React的声明式更新，数据处理逻辑变成了命令式，且必须格外注意清理工作。力导向图的仿真内部有定时器在持续运行，组件卸载时如果不调用simulation.stop()，它会一直占着CPU；同理，事件监听、setInterval驱动的动画也都要在useEffect的返回函数里清理干净，这是内存泄漏的重灾区。
方案三：按职责拆分，混合模式取长补短
实际项目里更常见的做法是折中：静态结构交给React渲染，动态部分交给D3。比如画一张带过渡动画的柱状图，坐标轴、网格线、矩形柱体这些静态结构用React写，而数据更新时的高度过渡动画用D3来驱动。实现思路是让React只输出元素的初始状态，更新时用useEffect里的D3去改属性。
import React, { useRef, useEffect } from 'react';
import * as d3 from 'd3';
function AnimatedBars({ data }) {
const gRef = useRef(null);
// React负责结构：每个柱子就是一个rect元素
useEffect(() => {
const g = d3.select(gRef.current);
g.selectAll('rect')
.data(data)
.transition() // D3负责动画
.duration(750)
.attr('y', (d, i) => 280 - d * 20)
.attr('height', d => d * 20);
}, [data]);
return (
<svg width={600} height={300}>
<g ref={gRef}>
{data.map((d, i) => (
<rect key={i} x={i * 45 + 20} y={280}
width={30} height={0} fill="#4a90d9" />
))}
</g>
</svg>
);
}这种模式下有一个必须遵守的纪律：React渲染的属性写初始值，D3只更新这些属性，双方不要同时改同一个属性。一旦React在re-render时也去设置y和height，动画就会被瞬间打断。可以通过约定命名来规避，比如React负责布局类属性（x、width、fill），D3负责数值类属性（y、height），代码层面就能形成清晰的边界。
选型建议与常见坑总结
三种方案怎么选，可以按需求复杂度来分：如果只是静态图表或简单交互，首选方案一，纯声明式最省心；如果图表涉及物理仿真、复杂拖拽、频繁的连续动画，方案二更合适；大多数业务图表处于中间地带，方案三的混合模式平衡得最好。另外，如果项目里图表类型比较常规，也可以直接考虑ECharts或Recharts这类React友好的封装库，没必要所有场景都硬上D3。
最后列几个高频踩坑点：第一，不要在render函数体内调用D3的DOM选择器，应该在useEffect里执行，因为render阶段不能保证DOM已提交；第二，所有D3创建的定时器、仿真、事件监听都要在清理函数里销毁；第三，数据量很大时（上万节点），SVG性能会成为瓶颈，考虑切换到Canvas渲染，D3同样提供了d3.select(canvas).getContext('2d')配合绘制的能力，这时的架构反而更简单，因为Canvas不存在DOM元素归属之争，React和D3彻底解耦。
总的来说，D3和React的结合没有银弹，核心是先想清楚渲染主控权的归属，再据此选择对应模式，并在团队内保持一致的约定，这样才能让数据可视化部分和业务代码一样长期可维护。