企业官网建设流程全解析

做了这么多年数据可视化，被问得最频繁的问题之一就是：ECharts 和 AntV 到底怎么选？特别是这两年可视化大屏遍地开花、BI 平台集中自研、金融系统都在做行情可视化，几乎每轮技术选型都会把这两个名字摆在一起对比。我的观点一直很明确：从来就没有“哪个更好”，只有“哪个更适合你的业务上下文”。这篇我不打算和稀泥，会把两家的底牌、大屏/BI/金融系统三个高频场景的适配度，以及我在真实项目里踩过的坑全讲透，最后给你一套拿到项目就能直接套用的决策路径。

先交代一下背景：我做过智慧园区大屏、自研 BI 报表平台、证券行情分析前端，也带团队搞过统一可视化组件库。这三个领域恰好是最容易把 ECharts 和 AntV 拿到台面上反复PK的地方。下面的内容不是我临时整理的技术对比文档，而是这些年从实际项目里沉淀出来的选型经验。

1. 先看家底：ECharts 和 AntV 走的是两条完全不同的路线

很多人在选型时犯的第一个错误，是默认这两个是“同类竞品”。实际上它们只是最终交付物看着像，底层思路差得很远。搞清楚这个差异，后面所有的场景选型都会顺理成章。

1.1 ECharts：最像“万能工具箱”的可视化方案，兜底能力极强

ECharts 出身百度，现在是 Apache 基金会顶级项目，国内前端圈几乎没有不认识它的。它最大的特点是“图表类型极全、配置项极多、社区实例极丰富”。从基础的折线柱状饼图，到 K线图、桑基图、主题河流图、自定义系列，你都能直接找到官方示例或社区改造版本。这对项目来说意味着什么？意味着无论产品经理提出多刁钻的图表需求，你大概率都能在半天内先出一个 demo，而且坑都有前人蹚过，出问题能找到答案。

另一个常被忽略的优势是渲染方案。ECharts 默认用 Canvas 渲染，但它也支持 SVG 渲染，两者可以按需切换。Canvas 适合数据量大、频繁刷新的场景；SVG 在图表数量多、节点层级复杂、需要无障碍访问的场景下有天然优势。这种“双渲染引擎并行”的能力，让它在工程落地时非常灵活。我在做大屏项目时基本无脑选 ECharts，就是因为它的动态效果、地图集成、大屏常见的渐变和光晕效果实现路径都很成熟，随便搜一个可视化大屏模板，底层十有八九是 ECharts。

不过 ECharts 也有明显短板。它的“灵活”也是一把双刃剑，配置项太自由意味着团队如果没有自己的规范约束，很容易做出风格混乱、坐标轴标签私自改动、色板五花八门的报表。另外，ECharts 本身更偏“提供图表能力”，不替你做视觉设计决策，它也不关心配色是否统一、图表间距是否符合阅读习惯。这些问题如果你在 BI 产品里不提前治理，后期一定会失控。

1.2 AntV：不止图表库，而是一整套可视化设计体系

AntV 是蚂蚁集团的可视化方案集合。注意“集合”这个词，它不是一个单一的库，而是按场景拆成了 G2 / G2Plot、G6、L7、X6、S2 等多个产品线。G2 是底层统计图表语法，官方定位是“数据可视化语法”；G2Plot 是基于 G2 封装的高交互图表库，主打开箱即用；G6 是图分析引擎；L7 是地理空间可视化；X6 是图编辑引擎；S2 是多维表格。这套体系背后的设计原则，是蚂蚁内部积累的《蚂蚁数据可视化设计规范》和色板、字体、间距等整套规则。

AntV 的核心竞争力也因此浮出水面：如果你不是只做一两张大屏，而是要搭一个长期演进的数据可视化产品，AntV 能提供的不是“怎么画图”的实现，而是“图表应该长什么样、怎么和用户交互、颜色怎么定、视觉怎么统一”的上层方法论。它更像一套装修标准，连带硬装软装的规格一起给你；ECharts 更像五金工具箱，随手能拿出来用，但室内设计得你自己来。

这里要补充一个最重要的判断维度：AntV 的学习曲线比 ECharts 陡得多。G2 参照了统计学家 Wilkinson 的《图形语法》，主张把数据、映射、几何标记分开描述，理解这个思想需要时间。团队里如果只有一个人做过 AntV，其他人都是 ECharts 出身，那前期的踩坑成本会很高。这也是很多团队拿它和 ECharts 对比后，又退回 ECharts 的直接原因——不是 AntV 不好，是团队学习成本没算进选型成本里。

2. 大屏、BI、金融三大场景逐个拆解，到底谁更合适

搞清了家底差异，接下来看三个典型场景。我直接给结论，再解释为什么——这个部分的内容大多是项目经验，不是 API 文档能告诉你的。

2.1 可视化大屏：ECharts 仍是主力，注意 L7 这类 GIS 例外

大屏场景的诉求，说白了就是“一眼震撼”。乙方要拿它汇报，甲方要它展示数字化成果，大屏要的是视觉冲击力、整体氛围、信息密度合理。这种场景下 ECharts 的优势非常突出：

第一，动态效果成熟。大屏最常用的柱状图流光渐变、折线图面积堆叠、地图标记点扩散、自动轮播数据，ECharts 的示例库里一搜一大把，改改 option 就能上。第二，大屏适配方案完善。大屏项目常规做法是设计稿定 1920x1080 或更高分辨率，前端做等比缩放，ECharts 在这种“固定尺寸 + 整体 transform”的模式下表现稳定，不会因为页面 scale 出现奇怪的渲染模糊问题。第三，主题定制成本低。ECharts 支持自定义主题注册，大屏常见的深色底、霓虹色系、科技感边框，通过配置 backgroundColor、颜色数组、阴影和光晕就能快速实现。

很多人问大屏字体怎么设置，其实大屏项目里真正重要的不是某个图表里文字的 font-size，而是整屏的字体适配策略。我的经验是：优先用固定设计稿尺寸做全屏缩放，不用 rem 或 vw 做图表内文字，因为缩放后会导致文字和图形比例失衡，出现文字偏大或偏小的问题。图表里的文字直接在 option 里写死字号，配合整屏缩放坐标系，显示效果最稳。

但 L7 是个例外。如果大屏的核心不是图表而是真实地理位置分析，比如城市路网、人员轨迹、区域热力，需要和底图、行政区划、3D 建筑模型打交道，那 L7 的 WebGL 能力、地图渲染能力和空间数据处理能力会比 ECharts 强很多。更准确地说，ECharts 的地图偏“示意”，适合做宏观省份/城市着色，L7 则能承载更真实、更实时的地理数据。大屏项目如果恰好是“地理底图上叠业务图表”，常见组合是 L7 做底图图层、ECharts 做浮层图表。

2.2 BI 平台：图表不是核心，规范和 S2 这类数据表格才是胜负手

BI 场景和大屏的逻辑完全不一样。BI 要的是“长期耐看、准确表达、用户可以反复操作”，而不是“一眼震撼”。在 BI 产品里，用户会花费大量时间看同一个图表，任何颜色刺眼、标签遮挡、交互不跟手的问题都会被放大到难以忍受。我参与自研 BI 报表平台时，最开始用的就是 ECharts，功能实现很快，但后续问题慢慢浮现：不同报表的图表风格对不齐，坐标轴格式各写各的，颜色总是有人临时改硬编码，最终图形产物越来越乱。

后来我们迁到 G2Plot，核心收获不是“图表能力更强”，而是设计规范被以代码的形式带进了团队。G2Plot 默认就带了合理的间距、色板、坐标轴样式，且推荐了统一的视觉规则，开发就算对设计不敏感，产出的图表也基本能维持统一水准。这对 BI 类产品是决定性的加分项。

另外，BI 领域非常容易被忽视的是“表格可视化”。BI 一半以上的页面不是图表，而是大量带分组、汇总、排序的数据表格。AntV 旗下的 S2 就是专做这个的：透视表、明细表、多维分析、表头冻结、单元格融合，配合行列维度和指标配置，能直接支撑起 BI 表格层的核心能力。而 ECharts 生态里没有对标的表格方案，你只能自己用 Ant Design Table 或其他组件库去拼，多级表头、树形展开、复杂小计汇总的逻辑写起来非常痛苦。

所以我的结论很直接：如果要做的产品核心是“分析产品”，比如 BI 平台、报表系统、数据洞察工具，AntV 体系是更优选；如果只是某个业务后台里需要几个统计图表，ECharts 的性价比更高。这个结论不取决于图表本身好不好看，而是规范能力、表格补充能力、产品长期演进成本这三项的综合结果。

2.3 金融系统：K线、高频刷新、暗色终端，ECharts 暂时没有对手

金融场景有自己的特殊需求，这也是我在实际项目里感受最深的部分。首先是 K线图，ECharts 原生支持 candlestick，并且能配合 dataZoom 做时间轴缩放、配合 markPoint 标注买卖点、配合 tooltip 看详细 OHLC 数据，一整套逻辑拿来即用。AntV 体系里目前没有直接对标 K线的现成图表，G2 图形语法虽然可以通过自定义几何标记拼出蜡烛图，但你要自己处理涨跌配色、均线叠加、缩放联动、十字光标这些金融终端的标配交互，开发量不是一个量级。

其次是高频数据刷新。金融行情页要的是“每秒不抖”，包括 canvas 渲染效率、setOption 的合并性能、图表 tooltip 在数据更新时是否闪烁、折线图新增数据点时是否有明显卡顿。ECharts 在大数据量下表现成熟，配合关闭动画、开启 progressive 渲染、用 appendData 增量追加数据，能稳稳跑出流畅的实时曲线。这方面我们的实践是：行情接口推数据到位后，前端用一个滚动 buffer 维护最近 N 根K线，setOption 用不合并方式整体替换，配合 echarts.graphic 在 canvas 上做买卖点标记，性能表现能稳定在 60 帧。

第三是终端 UI 习惯。金融系统的视觉风格普遍偏“密集信息 + 暗色背景 + 键盘操作 + 专业盯盘”，ECharts 深色主题、紧凑布局、细粒度配置都很贴合这类终端场景。AntV 的设计 DNA 更适合偏白底、留白多、面向运营和分析师的产品界面，放到暗色盯盘终端里要花不少精力去推翻默认样式。结论干脆一点：做真实行情终端的可视化层，目前我还是首选 ECharts；AntV 更适合金融机构内部的运营分析后台、用户画像看板这类偏 BI 属性的产品。

3. 技术维度硬碰硬：渲染、性能、地图、集成能力对比

场景结论给完了，还得给点硬核的技术参照，方便你在评审会上有数据可讲。下面这张表是我在实际项目中反复对照过的核心维度，不是权威 benchmark，但足够支撑选型判断。

3.1 渲染方案、包体与大数据量性能

渲染方案直接决定性能和交互细节。ECharts 默认 Canvas，在图表数量多但单个图元简单时，Canvas 的绘图效率高；但如果页面里有几十个小图表，且每个图表图形简单，SVG 也不差，毕竟 SVG 对 DOM 事件支持更友好，tooltip 和点击交互天然精确到图元。在 ECharts 里切换渲染方案只需要在 init 时加一个参数，这个能力在项目里很实用。

包体方面，ECharts 常被诟病体积大，但它支持按需引入，实操中只注册当前项目用到的图表组件就行。我一般这样配置：

import * as echarts from 'echarts/core'; import { BarChart, LineChart, PieChart } from 'echarts/charts'; import { GridComponent, TooltipComponent, LegendComponent, DataZoomComponent } from 'echarts/components'; import { CanvasRenderer } from 'echarts/renderers'; echarts.use([BarChart, LineChart, PieChart, GridComponent, TooltipComponent, LegendComponent, DataZoomComponent, CanvasRenderer]);

这个方案的 gzip 后体积能压到 300KB 以内，比全量引入省一半以上。G2Plot 按需引入做得也不错，但它的底层 G2 是整套图形语法，只要需要自定义图表，核心依赖就没办法裁得很干净。如果项目对首屏体积极敏感，ECharts 的更细粒度按需引入会是加分项。

大数据量下的表现，我拿真实场景举例。之前做物联网设备监控，单屏要画 5 万点以上的实时曲线，ECharts 的做法是animation: false配合progressive: 2000，让 canvas 分片渐进渲染，首屏不会卡死。G2 同样能扛大数据量，但你要理解它的 grammar 分层机制，G2Plot 层的数据量和自定义控制不如直接用 G2 灵活，这就是从 G2Plot 往 G2 下沉的原因。

3.2 地图/地理可视化与三维扩展

ECharts 和 AntV L7 在地图能力上的差异，比图表能力差异更明显。ECharts 的 map 系列本质是“地理坐标到平面图形的映射”，加载 GeoJSON 注册地图后，用系列数据驱动区域着色、标签展示和涟漪效果。它适合省、市、区县层级的行政分布图、迁徙图以及常见的“中国地图大屏”，网上教程和现成省份 GeoJSON 资源非常多。

L7 则是专业级地理可视化引擎。如果大屏需要叠加真实路网、实时轨迹、GPS 点聚类、网格热力、3D 建筑白膜，L7 的 WebGL 渲染和对 Mapbox / 高德底图的深度结合是 ECharts 无法企及的。项目里我们做过一个物流大屏：底图用 L7 渲染全国干线路径，浮层用 ECharts 渲染各个枢纽的吞吐量柱状图，各取所长，配合起来效果很好。

三维扩展方面，ECharts 生态里有 echarts-gl，能实现基础的 3D 柱状图、3D 散点、3D 地球、球面扫描等效果，很多大屏项目用这套做“科技感”主视觉。不过 echarts-gl 的配置项文档相对少，调试成本偏高，复杂 3D 场景更建议直接上 Three.js 或 L7。我的经验是：3D 效果在可视化大屏里只适合做开局主视觉，不适合做成信息承载主体，一旦需要用户操作或频繁刷新，3D 的渲染开销和交互复杂度会指数级增长。

3.3 工程集成：React/Vue 生态、主题定制、TypeScript 支持

工程集成层面的差异会直接影响团队研发效率。React 项目里 ECharts 有成熟的 echarts-for-react，封装了 resize 监听、option 更新合并和主题切换；Vue 项目有 vue-echarts，上手成本几乎为零。AntV 官方也提供 React 封装，但更新节奏和覆盖度不如 ECharts 社区丰富。如果团队规模不大，不想花时间维护统一封装层，ECharts 的社区红利会省很多事。

主题定制是另一个分水岭。ECharts 主题用 JSON 定义颜色、文字、线宽等 token，注册主题后所有图表统一生效；但默认主题和设计风格无关，最终是否好看取决于团队样式管理。AntV 则自带一套完整设计规范，从色板、字体、间距到图形样式都有推荐值，团队如果不想纠结视觉规范，AntV 的“默认值即高分答案”特性很有吸引力。

TypeScript 方面两者都做得不错。ECharts 的 option 类型定义庞大，构建时也有类型推导，配合编辑器自动补全体验尚可；G2Plot 的 API 类型设计相对现代，chart 的 config 对象有清晰的类型提示。实际项目里我更看重的是“自定义 chart 时类型是否给你兜底”，在这个维度上 G2 这种通过对象组合完成映射的写法，类型更清晰，ECharts 的自由配置型 option 在复杂自定义时经常要自己声明 interface。

4. 别凭感觉选：一套可以直接套用的三分钟决策路径

方法论讲再多，最后还是得落到“我这个项目到底选谁”。下面这套决策路径是我每次做选型评审都用的框架，你照着走，基本不会跑偏。

4.1 第一步先想清楚：你要的是“一张图”还是“一套可视化产品”

这是所有问题的最上游。如果需求是“后台订单趋势图”“部门月度统计柱状图”这种单图、散点式需求，直接选 ECharts。理由很简单：上手快、模板多、不需要为单张图引入一整套设计体系和语法框架。就好比你只是家里墙壁需要补个漆，不需要把整个装修队的规范手册拿来看一遍。

反过来，如果公司要做自研 BI、数据中台的可视化底座、统一报表平台，或者你会持续接入几十上百个分析页面，那必须按“可视化产品”来选型。这时候 AntV 的体系化优势就会展现出来——S2 补位表格场景、G2Plot 统一统计图表、设计规范约束视觉产出。单看第一张图，AntV 不一定比 ECharts 快；但做到第三十个页面时，AntV 的规范红利会越来越明显。

4.2 第二步对照场景清单，锁定候选方案

我整理了一张最简单直接的对照表，评审会时可以直接贴出来：

这张表不是“一个项目只能选一个”，很多中大型项目最后是“ECharts + AntV 子产品”混用。但要避免的是“主要技术栈不定，今天 ECharts 明天 AntV”的来回摇摆，那比选错更伤项目。

4.3 第三步评估团队执行方式和长期维护成本

最后回到团队本身。这里我建议负责人做三个问题的自我审视：

第一个问题：团队现在能熟练用 AntV 的人数超过 1 人吗？如果只有 1 个人熟悉 G2 图形语法，其他人只会 ECharts，那即使 BI 产品更适配 AntV，从工程经济性上看也要先考虑 ECharts 起步，后期再局部引入 G2Plot。技术选型最忌讳把团队变成单点瓶颈。第二个问题：产品有没有专职设计师？有设计师并且愿意沉淀图表设计规范，ECharts 完全可以把规范以配置和主题的形式落地；没有设计师，AntV 的默认规范能兜底视觉下限。第三个问题：项目维护周期是几个月还是几年？短周期交付型项目，ECharts 效率最高；长周期产品型项目，AntV 的体系化沉淀价值更大。

5. 真实项目踩坑记录：这些坑和库本身无关，但直接影响选型

最后分享一些实际项目中踩过的坑。这些经验比较碎，但对正在做选型或已经上车的人非常有参考价值。

5.1 ECharts 大屏项目：resize、防抖、地图数据和内存泄漏

大屏项目最容易踩的第一个坑是自适应。很多后台项目直接把 ECharts 放进响应式布局里，窗口一变就乱。大屏的正确做法是先确定设计稿尺寸和缩放容器，图表实例基于固定视口尺寸创建，页面整体放大缩小由外层容器 transform 控制。如果窗口变化是真实需要，resize 事件里一定要做防抖：

let timer = null; window.addEventListener('resize', () => { clearTimeout(timer); timer = setTimeout(() => { chart && chart.resize(); }, 200); });

第二个坑是地图数据。ECharts 的 GeoJSON 如果用了未简化的大区级边界数据，动辄十几 MB，页面加载直接白屏。我的经验是先通过简化工具降低 GeoJSON 精度，例如把坐标小数点从 6 位降为 2 位，体积能降 70% 以上，视觉差异肉眼几乎看不出来。还有内存泄漏问题：大屏长时间运行后，切换页面和重建图表频繁时，一定要调用chart.dispose()而不是只清空 DOM。没有 dispose 的实例会持续挂在内部渲染器上，时间长了页面明显卡顿，这是大屏现场演示最常见的翻车原因。

第三个坑是关于渐变色、光晕这类视觉细节。大屏项目里经常有人问柱状图怎么设置渐变色，其实 ECharts 在 color 里直接配 linear-gradient 对象就行。但你真正要注意的是不要全局渐变，因为渐变会让同一个系列在不同柱子上产生“单柱渐变”，视觉杂乱，建议只用在重点强调、最大值高亮等场景。

5.2 AntV 项目：自定义能力很强，但文档要往“语法”层面读

使用 G2Plot 时最痛苦的时刻是“文档里找不到某个配置”。原因是 G2Plot 的图表配置封装在顶层，很多控件需要通过 G2 的底层 view 实例去改。比如你想调整某个图例的点击交互，或者让 tooltip 在一张图里显示两行数据结构不同的内容，G2Plot 文档没有现成答案，得去看 G2 的语法。这不是文档差，而是这类库的设计本来就有分层：G2Plot 负责常见需求，G2 负责扩展。团队如果只停在 G2Plot 文档层面，自定义需求会做得很痛苦。

同样的问题存在于 S2 表格。S2 的能力很强，但配置项极多，尤其是主题定制、单元格交互回调、自定义布局这层，踩坑一次要翻好久源码。我的建议是：S2 适合产品里已经有明确表格形态再引入，不适合临时救火式的“先拿透视表顶着”，否则学习成本会吃掉交付周期。

5.3 双库并行的工程化细节：按需引入和主题变量隔离

不少团队最终会选择双库并行，比如“ECharts 做营销大屏，G2Plot 做后台分析报表”，这完全没问题，但工程化细节要注意。首先是按需引入要克制，不要图省事在入口文件里全局引入整个 echarts 和整个 @antv/g2plot，首屏体积会迅速膨胀。我当时给团队定过一条铁律：所有图表库一律按需引入，新增图表类型要走审批，避免它变成一个“下载了从来没人管”的重量级依赖。

其次是样式隔离。G2Plot 默认样式继承 Canvas 绘制，一般不会和 DOM 样式冲突；但 ECharts 的 tooltip、图例等涉及 HTML 结构的部分，会受全局 CSS 影响。我在一个项目里就遇到过全局 button 样式破坏 ECharts 图例按钮的诡异问题，排查了很久才定位到是选择器没有加作用域。双库并存时，建议把自定义 HTML 类名统一加前缀，避免样式串扰。

还有一个更容易被忽视的坑是“版本锁死”。ECharts 升级大版本时配置项可能不兼容，AntV 子产品之间也有版本联动关系（比如 G2Plot 和 G2 底层版本必须匹配）。团队里如果有人顺手升级了某个底层包，很容易引发隐藏的渲染异常。教训就是把这两个库的版本都锁进 package.json 的精确版本，升级必须排期并走完整回归测试。

6. 最后说点个人经验

如果非要我给一句话总结，我会说：选 ECharts 不容易出错，选 AntV 不容易走歪。前者解决“能不能快速画出来”，后者解决“长期演进是否可持续”。我见过把 ECharts 用出规范感的团队，也见过用 AntV 做出华丽大屏的团队，工具并不能决定上限，团队对可视化本质的理解才是。

这几年做选型评审，我的习惯是先写一份“非功能性需求清单”，把图表数量、数据量级、刷新频率、组件数量、团队熟悉度、维护周期、设计要求逐项列清楚，再去看库。没有把业务场景和团队情况先讲明白就吵 ECharts 和 AntV 谁强的，基本都是无效讨论。你现在打开一个项目，如果正好卡在选型这一步，把上面那张场景对照表拿出来过一遍，答案一般不会偏差太多。真要两个库都拿不准，就挑一个最贴近主场景的开始做，小范围跑两周再决定，比开会争论一个月有用得多。