花了三周时间，把主流的 Web 数据可视化与分析库逐个拉起来跑了一遍，翻了几百个 issue，写了十几个完整的上手 Demo，最后才有了这篇评测。
促使我做这件事的初衷很简单：数据科学社区里关于“Python 画图用 Matplotlib 还是 Seaborn”“前端图表用 ECharts 还是 Chart.js”的讨论太多了，但绝大多数停留在 API 层面。真正把项目从本地 Notebook 搬到 Web、从单人分析变成多人协作、从静态截图变成可交互系统时，选型逻辑完全不一样。我见过太多人用 Matplotlib + Flask 拼出一个人人都要单独装的报表页面，也见过有人一上来就学 D3.js，写了三天还没画出第一张散点图。
这篇评测不会给你一个“最好”的答案，因为不存在。我会把主流方案放进数据科学场景里，说清楚每个库适合谁、解决什么问题、在什么规模下会翻车，以及我在实盘操作中踩过的坑。
1. 评测的基本盘：我关注的七个维度和三类用户场景
1.1 为什么选型前先要确认自己属于哪类玩家
数据科学与 Web 数据可视化的组合，看起来都是“把数据画在网页上”，但实际需求千差万别。以我在评测过程中的观察，用户基本可以归为三类。
第一类是Python 数据科学家的个人探索：数据在 Pandas 里、在 Jupyter Notebook 里，希望快速生成可交互的图表放进 Web 项目。这类用户的核心诉求是“少写代码、快速出图、能嵌入 Flask/Django”。
第二类是前端工程师/数据产品开发者：目标是把图表作为产品功能的一部分，可能是大屏、后台报表、用户行为分析界面。这类用户更在意性能、配置自由度、设计一致性，以及图表库和前端框架的整合成本。
第三类是数据分析团队的整体基建：不只做一张图，而是要做 Dashboard、BI 报表、自助分析平台。这时候你选的不再是一个“图表库”，而是一整套“数据分析与可视化平台”。
我把这三类场景分别用 A、B、C 标记，后续每个库的评测都围绕它们展开。
1.2 七个评测维度的定义与打分逻辑
在逐个评测之前，我需要先说明自己用了哪些维度，免得后面给出的结论看起来像拍脑袋。
- 上手门槛：从零到画出第一张可交互图表需要多长时间，文档和社区资料是否完善。
- 表达能力：能覆盖多少图表类型——常规折线/柱状/散点不算能力，要看热力图、桑基图、3D 表面图、自定义图元等。
- 交互丰富度：缩放、平移、悬停提示、联动筛选这些交互是开箱即用，还是要自己实现。
- 性能表现：在 1 万、10 万、100 万行数据量级下，渲染、交互、内存占用表现如何。
- 技术生态整合：和 Python 生态、前端框架、数据库的对接成本，是否有官方或成熟的包装库。
- 可控性与定制化：遇到“图表库做不到但产品需要”的需求时，你能深入到什么程度去改。
- 部署与授权：License、依赖体积、是否支持离线部署、是否需要后端服务支撑。
每个维度从 1 到 5 打分，5 为最优。不搞加权总分，因为不同用户对权重的要求完全不同。下面的章节会逐步给出每个库在这些维度上的具体表现。
2. 交互开箱即用：Plotly 生态凭什么统治 Python 数据科学社区
2.1 从一行代码到一套 Dash 应用
Plotly 在 Python 数据科学社区的地位，可以用一个词概括：默认选项。它做了两件正确的事——把 Matplotlib 欠缺的交互性补上了，同时把出图逻辑包装得足够简单。
import plotly.express as px df = px.data.gapminder() fig = px.scatter(df, x="gdpPercap", y="lifeExp", size="pop", color="continent", log_x=True) fig.show()这一行代码生成的散点图自带缩放、悬停提示、图例筛选，输出 HTML 文件后直接放进 Web 服务器就能用。对于 A 类用户（Python 数据科学家），这是目前综合成本最低的交互式可视化方案。Plotly 的底层基于 D3.js 构建，但它把 D3 的复杂性完全藏了起来，你几乎不会感知到底层是什么。
Plotly 的第二个杀手锏是 Dash。它的逻辑是：既然图表已经是 Web 组件了，干脆把布局、交互回调、数据接口也一起做掉。
from dash import Dash, dcc, html, Input, Output import plotly.express as px app = Dash(__name__) app.layout = html.Div([ dcc.Dropdown(id="continent", options=[...]), dcc.Graph(id="chart"), ]) @app.callback( Output("chart", "figure"), Input("continent", "value"), ) def update_chart(continent): df_filtered = df[df["continent"] == continent] return px.scatter(df_filtered, x="gdpPercap", y="lifeExp") if __name__ == "__main__": app.run(debug=True)这套组合拳让它在这个赛道上几乎没有对手。Bokeh 也做类似的事情，但交互模式和视觉效果一直停在“工具”阶段，不够现代；pyecharts 只是给前端 ECharts 包了一层 Python，灵活性受限。我在评测中给 Plotly 的“上手门槛”打了 5 分，“表达能力”打了 5 分，“技术生态整合”打了 5 分。
2.2 Plotly 的舒适区与三处明显的“软肋”
先说软肋，否则容易让新手上头。
第一，大数据量下的性能衰减很明显。我拿一个 15 万行的时序数据测试，Plotly 生成的 HTML 文件有几十 MB，浏览器滚动和缩放明显掉帧。Plotly 的 WebGL 模式（scattergl）能缓解一部分压力，但依然无法和 ECharts 在 Canvas 层级的优化相比。
第二，定制设计系统很难。Plotly 提供 template 机制，可以统一下发主题，但由于图表类型多、属性层级深，真正做一套符合企业设计规范的主题要花不少精力。一旦你需要在图上叠加自定义 DOM 元素或复杂的动画交互，Plotly 会变得很棘手。
第三，缓存与文件体积问题。每个 Plotly 图表默认嵌入 Plotly.js 的完整代码，一个 HTML 文件动辄 5MB 以上。如果页面里同时放多个图表，需要手动把 JS 抽成公共资源，否则首屏加载会很慢。
我给 B 类用户的建议是：如果产品形态是“数据报告页”，需要用 Flask/Django 快速生成带交互参数的分析页面，Plotly 依然可靠；但如果是高并发、高频交互的数据产品，请继续看下一章的方案。
3. 前端图库与数据产品集成：ECharts 和 Highcharts 的真实差距
3.1 ECharts：国内数据大屏、后台系统的默认答案
ECharts 在 B 类场景里几乎是统治级的存在。一个很直接的原因是它生于中国、中文文档完备，加上 Apache 基金会项目的身份让它有很强的企业背书。过去三年我接触过的数据大屏项目，十个里有八个用的是 ECharts。
ECharts 的核心优势在于：它把性能、功能和配置自由度平衡得最好。基于 Canvas 渲染，百万级数据点的大屏不会卡死；配置项 JSON 化，这意味着后端可以生成配置，前端只负责渲染。它还内置了地图、树图、桑基图、仪表盘、关系图等 60 多种图表。
const chart = echarts.init(document.getElementById('main')); const option = { xAxis: { type: 'category', data: ['Mon', 'Tue', 'Wed'] }, yAxis: { type: 'value' }, series: [{ type: 'line', data: [120, 200, 150], smooth: true, areaStyle: {} }] }; chart.setOption(option);ECharts 5 之后强化了按需引入的能力，通过echarts/core和echarts/charts模块可以做到 Tree-Shaking，打包体积从完整版的 1MB 降到 300KB 左右。对于产品开发者，这是个关键指标。
在实际项目里我特别喜欢它的dataset组件。数据和配置彻底解耦，一个页面里多个图表共享一份数据源，后端只需要推送 CSV/JSON 数据，前端统一处理。联动高亮、下钻、多图联动这些交互，官方组件直接支持，不需要自己写。
在评测表现上，我给 ECharts 的“性能表现”打 5 分，“可控性与定制化”打 5 分，“上手门槛”打 4 分（因为配置项很深，需要一点时间）。综合是 B 类场景的第一选择。
3.2 Highcharts 的金融基因与授权问题
Highcharts 是老牌商业图表库，它在金融、保险、证券领域有很深的根基。理由很简单：图表类型非常专业，尤其是股票 K 线图、瀑布图、网络图，而且它支持 SVG 渲染，在图表大小不大时锐度很高。另外一个隐形资产是它的“无后端依赖”——纯前端渲染，兼容性好到连老版本 IE 都支持。
但它有一个绕不过去的坎：商业授权。个人学习免费，但公司项目、toB 产品、内部商业系统都需要购买 License。我的评测是从数据科学社区视角出发，对大多数独立开发者和中小团队来说，License 费用会直接改变选型决策。除非你的项目本身就在金融行业，或者客户明确要求 Highcharts（这种情况我遇到过），否则从工程角度没有理由选它而不是 ECharts。
3.3 pyecharts 不是“Python 版 ECharts”那么简单
很多 Python 数据科学用户会因为“Python 生成 ECharts 图表”这个诉求去用 pyecharts。我的实测结论是：可以，但不要抱太高期望。
pyecharts 的本质是在 Python 里拼接 ECharts 的 JSON 配置，所以它继承了 ECharts 的性能和图表表现力。但问题在于：
- 版本碎片化严重。v1.x 和 v2.x 的 API 变化很大，网上搜到的老教程大概率跑不通。
- 动态数据更新不如原生 ECharts 灵活。你是用 Python 生成配置、把前端交给 JS 去渲染，一旦涉及复杂的事件回调、组件交互，pyecharts 能做的事就很有限。
- 排错困难。它把错误传播变成“JSON 拼错了”，定位问题时要同时打开 Python 和浏览器 DevTools。
我的建议是：如果 Python 侧只是做数据处理，前台和交互都在前端完成，可以用 pyecharts 做原型验证，但要清楚它只是一个“配置翻译器”，不是图表的全部解决方案。
4. 深度定制的不同台阶：D3.js、Vega-Lite 与 Altair
4.1 D3.js 不是图库，是可视化原语工具箱
很多人在选型时把 D3.js 和 ECharts 放在一起对比，说实话这是不对位。ECharts 给的是“开箱即用的图表”，D3.js 给的是“从零搭建任意可视化的积木”。
D3.js 的核心能力体现在三个层面：一是数据到 DOM 的绑定机制，enter/update/exit让数据变化和图形元素的变化保持一致；二是丰富的几何计算函数，比如布局算法（力导向图、打包图、弦图）、比例尺、地理投影；三是强大的过渡动画系统。
但代价同样显著：学习曲线极其陡峭。我用 D3 做过一个跨 3 个部门的组织架构图，耗时是 ECharts 实现的四倍以上，但换来了完全自定义的交互效果和动画。对于绝大多数数据科学项目，这是个不值得投入的成本。
4.2 声明式路线：Vega-Lite 与 Altair 的价值
如果你想要 D3 的表达能力，又不想写底层 D3，该怎么办？答案在 Vega-Lite。
Vega-Lite 是基于 D3 之上的声明式语法。你在 JSON 里描述“数据”和“图形映射”之间的关系，它会自动帮你完成比例尺、坐标轴、图例、图层叠加这些底层工作。
{ "data": {"url": "data.csv"}, "mark": "point", "encoding": { "x": {"field": "gdpPercap", "type": "quantitative", "scale": {"type": "log"}}, "y": {"field": "lifeExp", "type": "quantitative"} } }Altair 是 Vega-Lite 的 Python 封装。它的设计哲学比较激进：只做统计图形，不做业务图表。也就是说，Altair 里没有现成的桑基图、仪表盘、大屏组件，但它做散点图、分布图、普通流的逻辑清晰得像数学公式。
Altair 的优势在中型数据集探索场景：
import altair as alt import pandas as pd df = pd.read_csv("data.csv") chart = alt.Chart(df).mark_point().encode( x="gdpPercap:Q", y="lifeExp:Q", color="continent:N", tooltip=["country:N", "lifeExp:Q"], ).interactive() chart.save("chart.html")这个操作和 Plotly 差不多，但 Altair 最终产出的是标准的 Vega-Lite 规范，意味着你可以在不同的渲染引擎间切换。不过它的交互深度有限，复杂联动需要自己写 Vega 表达式，数据量大时渲染性能也不理想。
评测结论：Altair 适合统计探索和学术场景，它能让你的图表背后有一套严格的统计语义，但如果你想构建产品级交互，它并不是高效的选择。
4.3 什么情况下你才需要亲自下场写 D3
结合我自己的项目经验，以下几种情况 D3 才值得选：
- 你需要一个现有图表库里绝对没有的可视化形态，比如自定义的弦图、和弦交互矩阵、自定义地图投影。
- 你对交互有极高要求：不仅限于“悬停显示数值”，而是要求图形元素和数据状态深度联动，比如拖拽、缩放、动画编排。
- 你的团队里有人能维持 D3 代码的长期维护。
否则的话，D3 只会让你花两倍时间完成别人一半的功能。Libra 项目的作者曾说过一个很精准的话：D3 是可视化工程师的乐高，而不是数据科学家的电饭煲。
5. 地理空间可视化：从 Leaflet 到 deck.gl 的能力分层
5.1 Leaflet：轻量地图交互的正确打开方式
地理数据是 Web 可视化里非常常见又容易被低估的领域。很多数据科学项目做到地图展示时，第一个想到的是 ECharts 的 map 组件，但一旦涉及高精度经纬度点、自定义底图、区域聚合，ECharts 地图就不够用了。
Leaflet 是轻量级地图库的常青树，我非常推荐 B 类开发者先尝试它。它以瓦片底图 + 标记点/矢量图层的方式工作，插件生态丰富，支持 MarkerCluster、Heatmap、Canvas 图层等。一个简单的带标记点地图：
const map = L.map('map').setView([39.9, 116.4], 10); L.tileLayer('https://{s}.tile.openstreetmap.org/{z}/{x}/{y}.png', { attribution: '© OpenStreetMap' }).addTo(map); L.circleMarker([39.9, 116.4], { radius: 10 }).addTo(map);Leaflet 的优势是体积小、性能平稳、API 直观，适合做“地图 + 数据标注”的中低密度场景。但它的渲染方式是 DOM/SVG，当同时渲染几千个标记点时，页面会明显变卡。此时需要配合 MarkerCluster 做聚合，或者转向下一层方案。
5.2 deck.gl、kepler.gl 与 pydeck：万级到百万级点数据的出路
当数据量到百万级，或者需要做 3D 柱状图层、弧线图层、区域热力图时，deck.gl 是我目前测试过的最优解。它基于 WebGL 渲染，可以在浏览器上处理数十万甚至百万个点的绘制与交互。
deck.gl 和 Pydeck 的组合让我很惊喜。Pydeck 在 Python 端暴露 deck.gl 的图层能力，数据可以直接从 Pandas DataFrame 传入：
import pydeck as pdk import pandas as pd df = pd.read_csv("shelter_locations.csv") layer = pdk.Layer( "ScatterplotLayer", data=df, get_position=["longitude", "latitude"], get_radius=200, get_fill_color=[255, 100, 100], pickable=True, ) view_state = pdk.ViewState(latitude=37.76, longitude=-122.4, zoom=11) deck = pdk.Deck(layers=[layer], initial_view_state=view_state) deck.to_html("map.html")kepler.gl 则更进一步，它是一个拖拽式的 Web 地理分析工具，不需要写代码就能做时空数据的聚合、过滤、播放动画。我在一次涉及几十万条行程轨迹的分析项目里用 kepler.gl 做临时探索，效果远比手动写代码来得直观。它的底层就是 deck.gl，所以性能和可扩展性都有保证。
地理空间这个方向，选型逻辑很清楚：数据量小、需求简单用 Leaflet；数据量大、需要复杂图层或 3D 用 deck.gl/Pydeck；团队里有非技术人员要自助探索时，上 kepler.gl。
6. 不写代码的团队级方案：Superset、Metabase 与 Redash
6.1 Apache Superset：数据团队内部的“SQL 可视化工作台”
到了 C 类场景——数据分析团队需要统一的可视化平台，选型逻辑完全变了。图表库的个人能力不重要，重要的是接入数据源的方式、权限管理、仪表盘协作、查询性能。
Apache Superset 是当前数据科学社区里最被看重的开源 BI 平台。它走的是 SQL-first 路线：配置好数据源（支持 MySQL、PostgreSQL、ClickHouse、Presto、Druid 等几十种），用户直接在界面上写 SQL，生成的结果可以一键变成图表和仪表盘。
我实际部署过 Superset 2.x，对它印象最深的是：
- 图表类型丰富，几乎覆盖了 ECharts 之外的单图表达需求。
- 支持 SQL Lab，可以在浏览器里直接查询数据库，对数据分析师非常友好。
- 权限体系完善，可以按团队、角色控制到每个仪表盘的查看/编辑权限。
- 部署偏重，官方推荐 Docker Compose，生产环境还需要 Redis、Celery 来跑异步任务，对运维有要求。
在我测试的环境里，连上 ClickHouse 后加载百万行聚合结果集的图表，响应时间可以控制在 2 秒内。它属于那种“前期投入高、后期能力强”的方案。
6.2 Metabase 与 Redash：轻量自助分析的另一条路线
Metabase 和 Redash 是 Superset 之外最常见的两个开源 BI 工具，但它们的产品哲学差别很大。
Metabase 主打“非技术用户自助分析”。界面设计非常友好，支持自然语言查询（比如输入“这个月的销售额按月份分组”），不需要掌握 SQL。它适合数据和业务之间的桥接——业务人员自己问问题，数据分析师不用持续写报表。但这也意味着它的可视化表达能力弱于 Superset，复杂仪表盘做起来很吃力。
Redash 的目标则更单一：SQL 查询与结果分享。它适合“查询数据 → 保存为图表 → 嵌入页面”这种轻量需求，但图表类型少、交互弱，不适合做大而全的分析平台。
我用一张表总结三者的定位差异：
| 平台 | 目标用户 | 需要SQL？ | 可视化深度 | 部署复杂度 | 适用场景 |
|---|---|---|---|---|---|
| Apache Superset | 数据分析师 | 需要 | 高 | 高 | 专业团队仪表盘、数据中台 |
| Metabase | 业务人员 | 不需要 | 中 | 中 | 业务自助分析、团队看板 |
| Redash | 开发/基础查询 | 需要 | 低 | 低 | 查询分享、嵌入式报表 |
从实际数据团队的选型经验看，Superset 和 Metabase 往往不是替代关系，而是共存关系：核心 KPI 看板用 Superset 维护，业务部门自己提数用 Metabase 开放权限。
6.3 部署、权限与语义层的坑
团队级数据可视化平台的最大问题不是图画不出来，而是基础设施。
我在部署 Superset 时遇到过一个典型问题：用 Docker Compose 默认部署，内存占用直接到了 3GB，导致低配服务器反复 OOM。后来通过限制 Celery worker 数量、关闭不必要的监控组件，才把内存压到 1.5GB 左右。如果团队没有运维能力，建议直接用托管服务或者选择 Metabase。
另一个容易被忽略的点是“语义层”。Superset 提供了虚拟数据集和计算列，可以在 SQL 之上定义统一的指标口径，但需要有人花时间维护。没有语义层之前，团队里不同的人对“销售额”的定义可能完全不同，画出的图表自然对不上。这一点在选型时比图表库本身更重要——工具只是载体，口径一致才是分析平台的灵魂。
7. 性能压测记录：我在真实数据量下看到的边界
7.1 各库在 1 万、10 万、100 万行数据下的表现
这是我最想分享的部分。评测过程中我造了一份包含时间、类别、地理位置、数值字段的模拟数据集，分别取 1 万、10 万、100 万行，测试各库手动渲染和交互体验。需要说明的是，我的测试环境是普通 MacBook Pro（M1 芯片、16GB 内存），浏览器为 Chrome。结果如下：
| 库 | 1 万行 | 10 万行 | 100 万行 |
|---|---|---|---|
| Plotly（scatter） | 流畅 | 有明显卡顿，悬停延迟 | 基本不可用 |
| Plotly（scattergl） | 流畅 | 流畅度尚可 | 缩放掉帧 |
| ECharts（Canvas） | 流畅 | 流畅 | 轻度掉帧但可用 |
| Altair/Vega-Lite | 流畅 | 卡顿明显 | 不可用 |
| deck.gl（ScatterplotLayer） | 流畅 | 流畅 | 基本流畅，偶发掉帧 |
| Leaflet（CircleMarker） | 流畅 | 卡顿 | 不可用 |
数据最能说明问题。A 类用户如果只是处理十万行以内的探索性数据，Plotly 完全够用；但 10 万行以上，ECharts 已经明显优于 Plotly，而百万级数据下，专业的 WebGL 方案 deck.gl 是唯一能保持交互相应速度的选择。
7.2 提升大数据可视化的三个通用思路
如果数据量已经超出图表库的能力，换库只是解决问题的一部分。这里分享几个我在项目中反复用到的优化思路。
第一个思路是数据降采样，而不是直接丢掉数据。时序数据可以用 LTTB 算法（Largest Triangle Three Buckets）抽稀，保持趋势曲线的视觉特征；空间点数据可以用四叉树或网格聚合。ECharts 的sampling: 'lttb'是内置的，直接开启就行。
第二个思路是后端聚合 + 前端渲染分离。让数据库完成 GROUP BY，图表只展示聚合结果。比如百万行明细数据，聚合到分钟级后只剩几千行，任何图表库都可以轻松处理。这个思路的关键是聚合粒度要跟着用户缩放级别走，而不是固定一个层级。
第三个思路是Web Worker 做数据处理。当图表需要在前端实时筛选百万行数据时，把数据过滤、统计的计算放到 Worker 线程，避免阻塞 UI 渲染。我在和 deck.gl 搭配时实测，10 万行数据的筛选计算从 200ms 降到 20ms 以内，体感提升非常明显。
最后再分享一个选型的私人经验。我在评估一个可视化方案时，会先问三个问题：数据量级是多少？用户会直接在页面上交互操作，还是只是观看？团队里谁能长期维护这段代码？这三个问题基本能过滤掉一半以上的选项。剩下的方案如果还选不出来，就各花半天写一个最小 Demo，放到真实数据上去跑一遍，比看任何评测都管用。评测能帮你建立候选清单，但最终决策一定要以自己的应用场景为准。
