React 数据可视化四剑客深度剖析：react-simple-maps、react-vis、recharts 与 victory

在 React 生态中，数据可视化需求常被简化为“选个图表库”，但实际工程决策远比这复杂。本文从真实开发场景出发，对比 react-simple-maps（地理专用）、react-vis（底层灵活）、recharts（声明式友好）和 victory（跨平台一致）的核心差异，助你避开选型陷阱。

🗺️ 地理可视化：谁真正懂地图？

react-simple-maps 是唯一专注地理可视化的库。它封装了 D3-geo 的投影逻辑，开发者只需提供 GeoJSON 数据即可渲染交互式地图。

// react-simple-maps: 渲染世界地图并高亮国家
import { ComposableMap, Geographies, Geography } from "react-simple-maps";

const geoUrl = "https://cdn.jsdelivr.net/npm/world-atlas@2/countries-110m.json";

export default function WorldMap() {
  return (
    <ComposableMap>
      <Geographies geography={geoUrl}>
        {({ geographies }) =>
          geographies.map(geo => (
            <Geography key={geo.rsmKey} geography={geo} />
          ))
        }
      </Geographies>
    </ComposableMap>
  );
}

其他三者 (react-vis, recharts, victory) 均不支持地理可视化。尝试用它们绘制地图需手动处理 GeoJSON 投影（如使用 d3-geo 计算路径），这违背了使用高层库的初衷。

💡 结论：若需求含地图，react-simple-maps 是唯一合理选择。否则，忽略此库。

📊 图表类型覆盖：基础 vs 扩展

常见图表（折线/柱状/饼图）

recharts 提供最直观的声明式 API：

// recharts: 声明式柱状图
import { BarChart, Bar, XAxis, YAxis, Tooltip } from 'recharts';

const data = [{ name: 'A', value: 400 }, { name: 'B', value: 300 }];

<BarChart width={500} height={300} data={data}>
  <XAxis dataKey="name" />
  <YAXIS />
  <Tooltip />
  <Bar dataKey="value" fill="#8884d8" />
</BarChart>

victory 采用类似但更模块化的方式：

// victory: 柱状图
import { VictoryBar, VictoryChart, VictoryAxis } from 'victory';

<VictoryChart>
  <VictoryAxis />
  <VictoryBar data={[{ x: 'A', y: 400 }, { x: 'B', y: 300 }]} />
</VictoryChart>

react-vis 需要组合多个底层组件：

// react-vis: 柱状图（需手动计算布局）
import { XYPlot, XAxis, YAxis, VerticalBarSeries } from 'react-vis';

<XYPlot width={500} height={300}>
  <XAxis />
  <YAxis />
  <VerticalBarSeries data={[{ x: 'A', y: 400 }, { x: 'B', y: 300 }]} />
</XYPlot>

特殊图表（桑基图、雷达图等）

• recharts：通过 Customized 组件扩展，但官方仅维护基础类型。
• victory：社区插件支持有限，核心库无高级图表。
• react-vis：曾提供 Sankey 等组件，但因停止维护，新项目风险高。

⚠️ 关键事实：react-vis 在 npm 和 GitHub 已明确标注为 archived（归档），官方不再接受 PR 或发布更新。新项目应避免使用。

🧩 定制能力：灵活度与成本权衡

样式定制

recharts 允许通过 CSS 或内联 style 覆盖默认样式：

// recharts: 自定义 tooltip 样式
<Tooltip contentStyle={{ backgroundColor: '#333', color: '#fff' }} />

victory 使用 style prop 传递对象：

// victory: 自定义柱状图颜色
<VictoryBar style={{ data: { fill: '#c43a31' } }} />

react-vis 依赖 CSS 类名（如 .rv-xy-plot__series--bar），需覆盖其内置样式表。

交互逻辑扩展

当需要自定义悬停行为时：

recharts 提供 onMouseEnter 等回调：

<Bar onMouseEnter={(data, index) => console.log('hover', data)} />

victory 通过 events prop 定义事件处理器：

<VictoryBar 
  events={[{
    target: "data",
    eventHandlers: { onClick: () => ({ mutation: () => ... }) }
  }]}
/>

react-vis 直接暴露 D3 事件对象，灵活性最高但抽象泄漏明显：

<VerticalBarSeries onValueMouseOver={evt => console.log(evt)} />

💡 工程建议：若团队熟悉 D3 且需深度定制，可考虑原生 D3 + React 封装；否则 recharts 的平衡性最佳。

📱 跨平台支持：Web 之外的世界

victory 是唯一官方支持 React Native 的库：

// React Native 中使用 victory
import { VictoryBar, VictoryChart } from 'victory-native';

<VictoryChart>
  <VictoryBar data={...} />
</VictoryChart>

其他三者（react-simple-maps, react-vis, recharts）仅限 Web 环境，因其依赖 DOM/SVG 特性。

✅ 适用场景：若产品需同时覆盖 Web 和移动端，victory 是唯一可行方案。

⚙️ 架构集成：与现代 React 的兼容性

Hooks 与函数组件

• recharts：完全拥抱函数组件，无 class 组件依赖。
• victory：新版全面支持 hooks，旧版有 class 组件残留。
• react-vis：最后版本（1.11.7）仍大量使用 class 组件，与 StrictMode 不兼容。
• react-simple-maps：函数组件友好，但需注意 GeoJSON 加载副作用管理。

TypeScript 支持

四者均提供官方 TypeScript 类型定义，但 react-vis 的类型因长期未更新，可能与最新 React 版本存在冲突。

🔄 数据流与响应式

recharts 的响应式设计最为成熟：

// recharts: 自动响应容器尺寸变化
<ResponsiveContainer width="100%" height={400}>
  <LineChart data={data}>...</LineChart>
</ResponsiveContainer>

victory 需手动处理尺寸变化：

// victory: 需监听容器尺寸
<VictoryChart width={containerWidth} height={400}>

react-vis 和 react-simple-maps 无内置响应式容器，需自行实现 ResizeObserver。

📌 选型决策树

1. 是否需要地图？

   • 是 → react-simple-maps
   • 否 → 进入下一步

2. 是否需支持 React Native？

   • 是 → victory
   • 否 → 进入下一步

3. 项目是否新建？

   • 是 → 排除 react-vis（已归档）
   • 否 → 若已有 react-vis 可维持，但勿用于新模块

4. 团队偏好？

   • 声明式、快速交付 → recharts
   • 跨平台一致性 → victory

🆚 核心能力对比表

💡 最终建议

• 地理需求：无脑选 react-simple-maps，别折腾其他库。
• 纯 Web 业务图表：recharts 是安全牌，文档全、社区大、上手快。
• 跨端项目：咬牙用 victory，尽管学习成本略高，但省去双端维护成本。
• react-vis：除非维护遗留系统，否则 不要开始新项目。

记住：没有“最好”的库，只有“最合适”当前约束的方案。评估时务必结合团队技术栈、产品生命周期和长期维护成本 —— 这才是专业前端架构师的核心价值。