这两年我帮团队搭数据看板、做分析报告、给客户交付各种 Web 端可视化项目被问到最多的问题永远是一样的数据科学这个行当里做 Web 数据可视化到底该选哪个库ECharts 够不够用D3 是不是更专业Plotly 真的好上手吗Bokeh 是不是已经过气了这个问题的背后其实是数据科学社区长期存在的“最后一公里焦虑”模型跑完了、指标算出来了、分析做完了但要把结果展示给业务方、领导、客户看总得找到一个顺手、好看、能交互、又不容易写崩的工具。市面上的库实在太多选型的成本甚至比写代码本身还高。这次我集中时间把全球主流的 Web 高级数据可视化与分析库统一做了一轮评测涉及 Plotly / Dash、Apache ECharts、D3.js、Vega-Lite、Observable Plot、Bokeh、Streamlit、Superset、Grafana 等 9 类方案。不吹不黑只看实际使用场景下的真实表现这篇就当作一次数据科学社区内部的选型参考笔记分享出来。1. 为什么要做这次评测1.1 数据科学的“最后一公里”被严重低估很多数据科学从业者把精力全放在建模、特征工程、指标监控上结果到了要交付图表的时候临时翻开一个可视化库的文档疯狂踩坑最后交出一张连自己都看不下去的折线图。我在多个项目中见过类似情况算法团队写的深度分析报告图是用 Excel 截的业务部门要的动态看板开发排期排了两周还没动手客户要的“大屏展示”最后变成了 PPT 截图投影。这不是个人能力问题而是选型混乱导致的系统性浪费。数据可视化在 Web 端的实现路径和数据分析阶段画图完全是两套逻辑前者要考虑浏览器加载性能、状态管理、前后端交互、主题定制、跨端兼容后者只需要在 Jupyter Notebook 里调用 matplotlib 画出来就够了。如果你还停留在“会用 matplotlib 就等于会做 Web 可视化”的阶段那这次评测对你应该很有参考价值。1.2 评测范围与选样逻辑先说明这次评测的选样范围。我筛选的三个硬性标准是第一必须是当前活跃维护、有稳定社区的项目第二必须支持 Web 端渲染或网页内嵌第三在数据科学工作流中具有较高的实际使用普及率。基于这三个标准最终进入了深度评测名单的是Plotly.js 与 DashApache EChartsD3.jsVega-Lite 与 Observable PlotBokehStreamlitApache SupersetGrafanaGrafana 和 Superset 严格意义上已经不属于“绘图库”而是完整的可视化和分析平台。之所以放进评测名单是因为数据科学团队经常把它们当作“Web 可视化选型”的落地载体很多人纠结的不是选什么图库而是选什么平台。分开讨论有助于理清边界。像 Chart.js、Highcharts、ECharts GL、Deck.gl、Mapbox GL 这些也很有名但考虑到定位差异我这次只会在对应章节里作为对比简单带过不展开全面评测。1.3 评测维度与打分方法为了避免“我觉得好看”这种主观判断我设计了一套尽量可量化的评测维度每个维度满分 5 分最后汇总成综合评分。实际评测过程中我会针对每个库写真实的可视化项目片段渲染同一份模拟数据集分别考察以下六个维度维度评测重点权重上手门槛从安装到画出第一张交互图所需时间20%表达能力图表类型覆盖、自定义程度、复杂可视化支持25%大数据量表现渲染 10 万级以上数据点的流畅度15%生态与集成与 Pandas、Scikit-learn、前端框架的配合15%交互与联动缩放、筛选、布刷、工具提示等交互能力15%定制与颜值默认主题、样式覆盖、企业级可塑性10%需要特别说明的是这个权重是按照“数据科学团队做 Web 端交付”的通用场景设置的。如果你做的不是数据科学交付而是纯前端大屏、高性能地理可视化、或嵌入式图表权重应该相应调整。这也是为什么后面给的选型建议不是一刀切而是按场景区分。2. 主流可视化库逐个拆解2.1 Plotly / Dash从分析脚本到交互看板的最短路径Plotly 是我个人在数据科学交付场景中使用频率最高的方案没有之一。它的核心价值在于你可以在 Python 里用非常接近 Pandas 思维的方式描述图表而不必切换到 JavaScript 语法栈。对于以 Python 为主要工具的数据科学团队来说这个优势直接决定了上手速度。我在评测中用 Python 读取一份包含 12 万行销售记录的数据画一个交互式折线图只需要把一个 DataFrame 直接传给plotly.express.line坐标轴、颜色、分组、工具提示全部自动生成。实测从项目环境建好到浏览器弹出图表不超过 5 分钟。如果拿 ECharts 做同样的事你需要先启动 Node 项目、安装依赖、定义 option 对象、再考虑数据格式转换时间成本明显更高。Dash 则是 Plotly 生态把交互看板延伸到应用层面的框架。它本质上是用 Python 写 Web 应用底层仍然是 Plotly 图表加 React 前端但对数据科学团队来说意味着可以用纯 Python 实现从前端布局到后台数据分析的完整链路。评测中我搭了一个包含 3 个联动图表和 2 个筛选下拉框的看板总代码量不到 200 行。这种集成效率在传统的前后端分离架构下至少需要 300~500 行代码还要单独配一个后端服务。当然Plotly 也有明显短板。它的自定义深度远不如 D3复杂布局和大规模定制常常要陷入 CSS 和底层 SVG 的泥潭。在大数据量渲染上默认的 WebGL 模式虽然比普通 SVG 好但和 ECharts 的优化比起来还是有差距。我在这轮评测中有一个 50 万点的散点图Plotly 在 Firefox 下出现了明显的掉帧而同一个图在 ECharts 里表现要好很多。适应场景我想压缩成三句话原型验证和快速交付选它Python 一体化团队选它需要前端极致定制的时候慎选。2.2 Apache ECharts国内社区绕不开的中坚力量ECharts 在国内数据可视化领域的地位基本相当于“默认选项”。我最早接触是在 2016 年当时它还是百度内部的图表库后来捐给了 Apache 基金会社区活跃度和迭代速度都保持在很健康的水平。它的最大优势是开箱即用的图表种类极其丰富从折线柱状饼图到桑基图、漏斗图、水球图、主题河流图几乎你能想到的常规业务图表都有。这次评测我特意重新用 ECharts 画了很多项目里常见的图表包括多轴联动折线图、大屏风格的仪表盘、地理信息热力图。它在审美上的起点明显比 Plotly 的默认样式要高默认主题配色成熟动画效果流畅而且对国内的大屏、后台管理系统的审美契合度非常高。如果客户对视觉呈现有要求ECharts 几乎是成本最低的选项。但 ECharts 的问题同样明显。首先它的核心语法是 JavaScript 对象配置数据科学团队如果不会前端用起来会有断层感。虽然官方也提供了 pyecharts 这样的 Python 封装但封装层和原生的 JS 能力并不同步一些高级配置要绕很大的弯才能通过 Python 实现。其次ECharts 对数据科学分析类图表的支撑并不算强比如统计分布、回归线、相关矩阵这类图表它不太擅长需要自己用散点图和工具函数去拼。在性能评测中ECharts 表现最稳10 万点以下的图表几乎无感50 万点散点图开启large: true后依然可以保持 40 帧以上这是 Canvas 渲染带来的优势。如果你对大数据量渲染有强需求ECharts 是这套名单里的第一梯队。适应场景同样是三句话前端团队为主的项目选它大屏和后台管理选它Python 数据科学团队纯后端使用时要谨慎评估 pyecharts 的局限。2.3 D3.js自由度最高写起来也最“酸爽”D3.js 是所有可视化库中的“天花板”我对它又爱又恨。爱的是它提供了从数据到 DOM 的完整操作能力你可以用 SVG、Canvas、CSS 甚至 HTML 拼出任何你能想象到的可视化形态恨的是它学习曲线陡峭调试成本高有很多低级错误会让你在浏览器 F12 面板里耗上一整天。这次评测我拿 D3.js 实现了一个自定义的“环形热力日历图”应该是 ECharts 和 Plotly 都没有现成图表类型的东西。数据绑定思想Data Join确实很强大你只要理解enter、update、exit三个阶段的数据操作逻辑几乎可以做到数据和视觉元素的一一映射灵活性碾轧所有高层包装库。对于数据科学团队来说D3.js 的价值不在于日常做图而在于做产品原型、做个性化定制的数据新闻、做需要和品牌深度融合的可视化系统。但必须提醒的是D3.js 不提供任何现成图表所有坐标轴、比例尺、图例、工具提示都需要自己搭。这意味着用 D3.js 完成一张简单柱状图的成本相当于用 ECharts 完成一个完整仪表盘的十分之一时间。它对数据科学任务的支持为零不会帮你做统计不会帮你做布局自由与代价完全对等。最终评测结果中D3.js 的“表达能力”打了满分但“上手门槛”打了 1 分是所有库中综合起伏最大的一个。我的建议是如果你的团队有专职前端或可视化工程师把 D3.js 作为深度定制的底层方案是值得的如果团队全是 Python 数据分析师建议不要在 D3 上面死磕用高层库节约的时间远比省下的性能更有价值。2.4 Vega-Lite / Observable Plot在简洁与严谨之间找到完美平衡Vega-Lite 是这批评测名单里带给我最大惊喜的一个系列。它采用声明式语法用 JSON 描述可视化的数据映射、坐标轴、图例和交互行为底层基于 Vega 渲染。简单说你在 Python、JavaScript、或者纯文本里定义一个规范对象Vega-Lite 自动帮你渲染出图表不需要关心具体绘制细节。实际评测中我用 Vega-Lite 重画了 Plotly 评测用的 12 万行销售数据折线图大概只用了不到 30 行 JSON 配置而交互式缩放、悬停提示、图例筛选全部原生支持。它的设计哲学很有“语言学”的美感把可视化拆解成 mark、encoding、transform、facet 等抽象概念一旦你理解了这个体系就能举一反三地表达非常复杂的图形。Observable Plot 是 Observable 团队在 Vega-Lite 基础上进一步简化的产物语法更简洁标记感更强特别适合快速探索性图表和“数据新闻”类的高保真输出。我在做评测时用它画了一个带误差棒的分组箱线图代码量只有 Vega-Lite 的一半但渲染出来的图表质感非常好默认样式几乎可以直接用于出版物。局限也很明显Vega-Lite 的生态相对小众中文资料少报错信息对新手不友好Observable Plot 对交互控制的能力偏弱复杂联动还是得回到 Vega 或者 D3。另外它们虽然能嵌入 Web 应用但和主流前端框架的整合程度不如 ECharts 和 Plotly 组件那么顺滑。对于一些“有前端工程师配合的数据科学团队”来说Vega-Lite 其实是被严重低估的高性价比选择。2.5 Bokeh与 Pandas 无缝衔接的老牌库Bokeh 在数据科学社区里属于“老资历”和 Plotly 差不多是同一时期出现的交互可视化方案。它有很强的服务端渲染能力可以直接把 Python 对象转换成网页应用提供交互式图表的完整后端支持。这次评测我着重复现了“多图联动筛选”和“服务端推送”两种使用场景看板和 Plotly-Dash 的效果相当接近。Bokeh 在金融数据、时序数据领域有相当忠实的用户群因为它的ColumnDataSource数据源模型和 Pandas DataFrame 配合非常自然。我在评测中把一份包含 20 万行分钟级股票高频数据直接塞进ColumnDataSource再用CustomJS做回调联动整体流畅度可以接受。但不可回避的是Bokeh 的生态活跃度和可视化颜值已经逐渐落后于 Plotly 和 ECharts。默认样式的“复古感”很劝退即使调整主题也很难达到现代商业产品的审美标准。社区里的新库、新图表类型更新也比较慢遇到特殊需求你能搜到的参考案例已经很少了。我的评价是如果你维护的是 3 年前甚至更早的老项目并且已经用 Bokeh 搭好了一套成熟的交互体系继续使用是完全合理的如果是新项目我不推荐从零开始选用 Bokeh。2.6 Streamlit偏向应用框架的快速方案严格来说Streamlit 不是绘图库而是一个 Python Web 应用框架但它在数据科学社区的热度早已超过了许多传统可视化库。它的使用逻辑是你写一段 Python 脚本用st.line_chart或st.plotly_chart组合图表和组件Streamlit 自动把脚本渲染成交互式 Web 应用。在这次评测中我用 Streamlit 复刻了 Dash 评测中的那个看板只用了一半的代码量。主要原因是 Streamlit 的页面布局是基于“自上而下执行”的脚本模型你不需要写回调函数改一个控件整个页面自动重新运行并更新。这种模型的优点是极快、极简单缺点是复杂交互状态下性能不高每次交互都会重新执行整个脚本。数据科学团队做内部工具、模型演示、项目 POC 的时候Streamlit 的体验可以用“爽”来形容。但我几乎不会把它用于客户交付的正式产品原因包括页面样式难以深度定制、多用户并发场景下资源消耗高、以及不适合复杂的前端交互设计。2.7 Superset / Grafana分析平台而非绘图库把 Superset 和 Grafana 放在一起说因为它们在实际选型中被混淆的频率最高。Superset 是 Airbnb 开源的数据探索和可视化平台核心能力是“连接数据源 → 配置数据集 → 拖拽生成图表 → 组装仪表盘”Grafana 则是更偏向基础设施监控的可视化平台主打时序数据和时间范围筛选在运维监控领域近乎垄断。评测中我在 Superset 里配置了一个连接 MySQL 数据源的多图仪表盘体验下来觉得它的图库深度不算顶尖但胜在平台化功能完整用户管理、权限控制、SQL Lab、图表共享一应俱全适合企业级报表平台。Grafana 则是另一个极端图表类型相对单调但胜在时序性能和告警生态成熟如果你想在 Grafana 里做销售数据分析、用户画像等业务报表明显会感觉施展不开。数据科学团队选型时容易犯的错误是用“数据分析的脑子”选“运维监控的武器”。Grafana 和 Superset 都属于平台方案如果你要的不是图表库而是一套能让人登录、操作、查询的完整系统才应该在它们中间选。否则还是回到 Plotly、ECharts、Vega-Lite 这类嵌入式库更合适。2.8 横向对比一览表为了让后续选型参考更直观我把九个方案的评测结果汇总成了一张总表方便快速定位。方案上手门槛表达能力大数据性能生态集成交互联动定制与颜值综合评分最佳定位Plotly / Dash4.54.53.55.04.03.54.2Python 数据科学交付看板Apache ECharts4.04.55.04.04.54.54.4大屏、后台系统、高复杂度图表D3.js1.05.03.53.05.05.03.6深度定制、专属可视化产品Vega-Lite3.54.53.03.54.04.03.8声明式、研究性可视化Observable Plot4.04.03.03.03.54.53.7快速探索、出版级图表Bokeh3.53.53.54.03.52.53.4老项目维护、金融时序Streamlit5.03.02.54.53.03.03.7内部工具、模型演示、POCSuperset3.03.53.54.53.03.53.5企业级报表平台、用户体系Grafana3.52.55.04.03.03.03.5监控、时序数据、告警这里的综合评分不是绝对权威只是按我预设的数据科学交付权重计算的结果。如果你的场景优先级不同评分肯定会变后续选型章节会详细说怎么基于自身场景做调整。3. 实测中的关键踩坑与性能对比3.1 大数据量渲染谁会在 50 万点崩掉每个库在“效果演示”时都很好看但到了生产环境数据量一上来就开始原形毕露。我这次用 50 万个随机生成的点作为统一测试数据分别测试了折线图和散点图两种常见形态记录浏览器掉帧阈值和内存占用情况。ECharts 的表现最让人放心开启动态缩放和采样优化后50 万点散点图可以保持稳定输出。但要注意一个细节ECharts 默认对大数据的处理是降采样不是在底层提升渲染上限所以如果你遇到图表“看起来变稀疏了”不要慌那是它自动抽稀了可以通过progressive和largeThreshold参数调整。Plotly 在 50 万点的情况下用 WebGL 模式打开Firefox 下出现了明显卡顿Chrome 稍好但拖动和缩放依然有延迟。D3.js 在 50 万点 SVG 模式下直接卡到不可用切换到 Canvas 后勉强可用但需要自己去写 Canvas 渲染逻辑和命中检测。实测共同结论是在大数据量场景下Canvas 是刚需SVG 只适合万级以下的数据量。选型时不要只看库的宣传是否支持大数据要确认你是用 SVG 渲染还是 Canvas 渲染两者性能差异完全不在一个量级。3.2 企业级样式定制与主题体系的差距我接手过好几个从原型走向产品的可视化项目发现很多团队在原型阶段用得很顺的库到了产品阶段却卡在“定制样式”这一关。这次评测里专门花时间对 ECharts、Plotly、Vega-Lite、D3 四类库做了主题定制压力测试。ECharts 的主题定制体系最成熟官方提供了主题构建器和丰富的设计规范你可以通过配置对象覆盖任何组件的颜色、字体、坐标轴样式还支持自定义地图注册和图形注册。Plotly 的主题定制能力相对较弱全局template可以设置基础样式但大量细节需要深入到layout和trace里逐项修改代码会迅速膨胀。Vega-Lite 的主题以配置为主命名规范清晰但底层的自定义能力有边界。D3 则完全没有“主题”概念一切都要自己写这也是它定制能力满分但工作量最大的原因。从实际交付角度我建议不要只看库本身能画什么还要评估和你们前端设计体系的匹配度。如果公司有完整的设计系统Design System选 D3 或者 ECharts 的深定制路径更合理如果只是快速交付一个数据产品Plotly 或者 Vega-Lite 的默认样式已经足够。3.3 服务端渲染与前端框架集成差异数据科学团队经常忽略一个关键问题可视化库能不能和服务端渲染SSR与主流前端框架无缝集成。你在 Jupyter 里画图没问题不代表放到 React/Vue 项目里也能顺利运行。ECharts 因为出身前端社区对 Vue、React 的支持非常完善官方提供了 echarts-for-react、vue-echarts 等封装组件还推出了 echarts 5 的 SSR 支持和按需引入方案。我在一个 Vue3 项目中引入 ECharts开启按需加载后打包体积从 1MB 降到了 300KB这个优化幅度很可观。Plotly 在 React 中有官方组件react-plotly.js但体积控制不如 ECharts而且在 Next.js 这类 SSR 框架里需要额外处理 window 对象相关的问题。D3 和 Vega-Lite 与框架的集成度算中等偏上因为它们本质上是 DOM 或 SVG 操作库只要在组件挂载后手动执行初始化即可但状态管理和响应式更新需要你自己设计。Streamlit 和 Dash/Grafana 则完全不适用“前端框架集成”这个场景因为它们本身就是完整框架适合自成一体的项目。4. 选型决策建议4.1 按场景匹配从业务需求倒推技术选型总结完评测数据之后最核心的问题是怎么做出最终决定。我根据自己的项目经验把数据科学团队常见的 Web 可视化需求分成五大类每一类都对应不同的推荐方案。第一类是“快速探索型”。你只是想把手里的分析结果变成能看、能交互、能分享的图表没有复杂的权限和包装需求这种情况我强烈推荐 Streamlit 或 Plotly。Streamlit 适合内部工具和模型演示Plotly 适合一次性的分析报告分享。第二类是“业务看板型”。需要展示核心指标、提供筛选条件、对接具体业务系统并且对视觉风格有要求。这种情况最推荐 ECharts其次是 Plotly Dash。前者适合有前端支撑的项目后者适合 Python 全栈团队。第三类是“企业级平台型”。要做多用户、权限管理、数据集管理、图表共享而且要可扩展可维护。这种场景直接选 Superset 或者 Grafana别在自己的代码里重新发明轮子。两者的边界很清晰偏业务报表选 Superset偏监控时序选 Grafana。第四类是“深度定制型”。产品需要高度个性化的视觉呈现、专属的可视化形式、复杂的交互逻辑。这种情况只有 D3.js 能带你到达目的地前提是团队里有能驾驭它的前端可视化工程师。第五类是“科研出版型”。图表要发论文、写报告、做数据新闻追求高信息密度和出版级的图形表现。Vega-Lite 和 Observable Plot 是很好的选择它们默认输出的图表细节非常考究。4.2 团队技能树是最高优先级的筛选条件看起来选型是在选“技术方案”实际上选的是“团队能力适配”。我见过太多团队因为看到一个库很酷强行引入最后却因为没有对应技能储备项目工期翻倍、代码质量崩盘。你现在的团队是 Python 数据分析师主导还是前端工程师主导直接决定了该选哪一条路线。Python 团队为主的场景闭眼选 Plotly 或者 Streamlit少走弯路。如果一定要做企业级平台用 Superset 而不是自研。前端工程师主导的场景闭眼选 ECharts 或者 D3.js性能、定制、集成都能得到更好的保障。至于 Vgea-Lite 和 Observable Plot适合团队里有人愿意花两周时间深入理解声明式语法的项目。Bokeh 在新项目中我基本不支持除非团队已经积累了很深的 Bokeh 定制经验。4.3 我的最终选择建议结合过去几年多个项目的交付经验我给出一个比较保守好用的组合策略常规业务可视化以 ECharts 为基底快速原型和 Python 深度集成用 Plotly需要数据新闻或者深定制的场景走 D3.js/Vega-Lite企业级平台直接引入 Superset。这个组合不是“最佳配置”而是在大部分商业项目里最不容易踩坑的方案。如果你正在启动一个全新的数据可视化项目先从上面提到的五大场景里找到自己属于哪一类再回到第 2 节的评分表里看对应的分数基本就能锁定主选方案。第二候选方案也保留着作为风险对冲。比如主选 ECharts 的项目如果发现团队 Python 基础更强可以把 Plotly 作为备选主选 Plotly 的项目如果客户审美要求很高可以把 ECharts 作为升级方向。这里还想多说一句可视化选型不要盲目追求“功能最全”或者“性能最强”。实际交付中用户最在意的是图表清晰、交互自然、加载不卡、与整体产品风格统一。这些指标和你用的库关系不大更多取决于你怎么设计数据编码、怎么安排交互层级、怎么规划渲染性能。库只是载体数据讲故事的能力才是核心。写在最后的实际操作体会这次把九个方案全部拉出来实测一轮之后我最大的感受是可视化选型从来没有“银弹”但确实存在“更不容易后悔的组合”。我在交付项目时最常用到的两个实用技巧可以作为参考收尾。第一个技巧是开始写图表代码之前先在纸上画出手稿。不管是给客户做看板还是内部做分析面板先和需求方确认清楚需要哪些图表、它们的布局关系是什么、筛选条件和图表之间怎么联动。很多时候需求方自己都不知道想要什么草图画出来之后他们才能给出有效反馈。我在多个项目中通过画原型草图把原本需要返工两周的需求问题在一小时内解决了后续写代码的过程也会非常顺。第二个技巧是建立团队的图表组件库。不管你最终选的是 ECharts 还是 Plotly把项目里常用的图表封装成带默认参数的组件制定数据格式规范写好配色主题和交互约定。这样新项目启动时可以拿来即用省掉大量重复的配置调试时间。我自己的团队把 ECharts 的十几个业务图表封装成了内部 npm 包开发效率提升了至少 40%工程质量也有明显改善。最后再提醒一句你选的不只是技术还是团队未来一两年的开发体验。不要因为一个库的某张演示图很惊艳就冲动选型拿真实的业务数据用团队的现有技能做一轮像这次评测一样的对照实测再下结论也不迟。