企业官网建设流程全解析

简介：ECharts关系图-关系图20.rar是一份面向前端开发者和数据分析师的可视化示例资源，聚焦ECharts关系图的实现与应用，特别适合数据大屏、社交网络分析和网络拓扑展示场景中呈现实体间的关联关系，也适合作为关系图开发的学习范本。压缩包内共3个文件，以ECharts 5.5.0图表库为基础，包含2个JavaScript文件和1个HTML文件，整体约970KB；JS文件承担图表初始化、数据定义与力导向布局等核心逻辑，HTML文件则是可直接运行的页面入口，打开就能查看关系图渲染效果，对照代码修改配置非常方便。资源已有102人下载学习，适合需要快速上手关系图、或想参考节点样式、连线交互和大屏配色方案的前端开发者。通过这份示例，读者能掌握关系图的数据组织方式、力导向布局参数调节、拖拽缩放与点击事件绑定等关键技能，还能将静态示例与后端数据源结合，改造成动态更新的大屏可视化项目，节省从零搭建的时间。

1. ECharts关系图：这不是一个Demo，是能把关系可视化直接落地的现成工程

第一次在真实项目里看到ECharts关系图，我脑子里想的是“这不就是个力导向图嘛”，结果真去做大屏可视化的时候才发现，节点怎么分布、边怎么连、数据从哪来、交互怎么做，每一个环节都能卡住半天。这份“关系图20”的压缩包，解决的正是这些事：它不是官方示例那种只跑通一个页面的玩具，而是把关系图常用的场景做成了可直接改数据的工程文件。解压后你面对的不是一堆没法复用的碎片代码，而是一套从数据格式到视觉配置都排好的关系图方案，尤其适合做数据统计分析和大屏可视化的人。不管你是刚接触ECharts的新手，还是已经在公司项目里踩过关系图坑的开发者，都会需要一个能快速改数据、马上看到效果、又能按自己需求调参数的起点。

2. 拆开关系图20：目录结构、数据格式与运行前提

2.1 解压后先看这几个文件

拿到压缩包，先不要急着双击HTML文件。我通常的习惯是先看目录结构，搞清楚哪些文件是可以删的、哪些是核心逻辑。这份资源里，主结构一般是静态网页工程的样子：一个HTML入口文件、一个存放关系数据的JS或JSON文件、一份图表配置脚本，可能还带一个说明文档。HTML入口负责初始化页面容器和加载ECharts，数据文件负责提供nodes和links，配置脚本则控制关系图的颜色、大小、力导向参数。

先把工程跑起来，是最重要的一步。如果你直接双击HTML文件，在Chrome里可能会遇到“跨域读取本地文件失败”的问题，因为浏览器禁止页面通过fetch去读本地的JSON文件。我一般会在项目根目录起一个静态服务，比如用Python的http.server：

cd ECharts关系图-关系图20 python -m http.server 8080

然后浏览器访问http://localhost:8080，页面就正常了。用这种方式跑起来的好处是，后续你改数据文件、换图片资源、加异步请求，都不需要再担心跨域限制。如果你机器上没有Python，用VS Code的Live Server插件也可以达到同样效果，本质上都是把目录当成了一个静态站点在服务。

看到这个包我先确认了三件事：ECharts版本是不是5.x、数据文件和配置脚本是不是分离的、有没有把节点坐标写死在数据里。这三件事直接决定了我后面改数据的成本。如果是写死坐标的图形，那它属于“布局先行”的静态关系图，改数据时需要重新计算坐标；如果配置脚本里没有显式坐标，用的是layout: 'force'，那么ECharts会自己算位置，这种更适合动态数据场景。这份资源里的配置，我更愿意把它当成一个“可复用的关系图基线配置”来看待。

2.2 nodes和links：关系图数据的标准格式

ECharts关系图的数据接口看起来简单，其实有不少细节。所有关系图都建立在两个数组上：nodes和links。nodes是节点数组，每个节点至少要有name字段；links是边数组，每条边至少要声明source和target，表示从哪个节点连到哪个节点。

// 关系图的基础数据接口示例 const graphData = { nodes: [ { name: '数据中台', category: 0, value: 90 }, { name: '业务库', category: 1, value: 60 }, { name: '明细层', category: 1, value: 75 }, { name: '汇总层', category: 2, value: 35 }, { name: '应用层', category: 3, value: 50 } ], links: [ { source: '数据中台', target: '业务库', value: 1 }, { source: '数据中台', target: '明细层', value: 1 }, { source: '业务库', target: '汇总层', value: 1 }, { source: '明细层', target: '应用层', value: 1 } ] };

这里有一个比较容易忽略的点：links里的source和target，既可以写节点的name，也可以写节点在nodes数组里的索引。用name直观，但要求节点名称在整张图中唯一；用索引稳定，但数据稍微一变动就容易错位。ECharts实际处理的时候，如果传的是字符串，它就会去nodes里找同名的项，找不到就把这条边忽略掉，而且不会报错。这也就是很多关系图“看起来少了几条线”却查不出原因的地方。

在这份资源里，节点上通常还会带category、value、symbolSize这类附加字段。category用于节点分类，配合图例显示不同颜色；value可以用来控制节点大小，也可以只在tooltip里展示；symbolSize则直接覆盖节点尺寸。我一般会保持value和symbolSize同时存在，因为value承载业务含义，symbolSize负责视觉表现，二者解耦后，后续做数据分析时逻辑更清晰。

2.3 关系图的主体配置：graph类型下的关键参数

在ECharts里，关系图对应的series类型是graph。它和普通柱状图、折线图最大的区别在于，数据不是简单的二维表格，而是图结构。一个最基础、能跑通的关系图配置，通常长这样：

option = { tooltip: {}, series: [{ type: 'graph', layout: 'force', data: graphData.nodes, links: graphData.links, categories: [ { name: '核心节点', itemStyle: { color: '#5470c6' } }, { name: '存储层', itemStyle: { color: '#91cc75' } }, { name: '计算层', itemStyle: { color: '#fac858' } }, { name: '应用层', itemStyle: { color: '#ee6666' } } ], roam: true, draggable: true, force: { repulsion: 100, edgeLength: 120, gravity: 0.1 }, lineStyle: { color: 'source', curveness: 0.2, width: 1 }, label: { show: true, position: 'right' } }] };

这段配置里最核心的是layout: 'force'，它表示让ECharts用力导向算法自动计算节点位置。力导向布局的思想是给每个节点一个电荷力，节点之间互相排斥，而构成边的节点又被弹簧力拉住，迭代收敛后形成一张相对均衡的关系网络。force.repulsion控制排斥力大小，数字越大节点分布越散；force.edgeLength控制边的理想长度，数字越大相邻节点离得越远；gravity是把所有节点往画布中心拉的力度，调大可以防止节点被甩出可视区域。

roam: true允许用户缩放和平移画布，draggable: true允许拖拽节点。这两个参数在大屏场景里我认为比很多样式参数都重要——关系图一旦复杂，用户需要通过拖拽和缩放来观察局部结构，如果禁用了这两个交互，图做得再好看也缺少可读性。lineStyle.color设为'source'时，边的颜色会跟随起点节点的颜色，这在分类场景里特别有用，一眼就能看出边的归属。

在这个包的基础配置上，我建议你做的第一件事不是调颜色，而是把data和links抽到独立的数据文件里。这样后续替换数据只需要改数据文件，不用频繁翻配置脚本。资源里的数据文件虽然通常不和HTML放在同一个文件里，但逻辑上已经分开了，你要做的只是把自己的数据按照同样的结构替换进去。

3. 把示例数据换成自己的业务数据：关系图从静态到可用的完整改造

3.1 先将业务数据映射成节点数组

关系图最终展示的是“谁连接谁”的结构。所以拿到一份业务数据，不管它是人员组织架构、设备拓扑还是交易链路，第一步都是把它拆成两个维度：节点维度、关联维度。比如你要展示一张数据库血缘关系图，每个表是一个节点，表之间的数据流向就是边。

常见做法是写一个转换函数，把原始列表转成nodes和links。我习惯在转换时同时做三件事：去重、补字段、校验关联完整性。下面这段代码是典型的转换思路：

function buildGraphData(rawTables, rawRelations) { const nodes = []; const nodeMap = {}; rawTables.forEach(t => { const node = { name: t.tableName, category: t.layer, // 根据分层归类 value: t.fieldCount, // 字段数作为权重 symbolSize: Math.max(20, Math.min(t.fieldCount, 100)) }; nodeMap[t.tableName] = node; nodes.push(node); }); const links = rawRelations .filter(r => nodeMap[r.source] && nodeMap[r.target]) .map(r => ({ source: r.source, target: r.target, value: r.jobCount })); return { nodes, links }; }

这段代码的核心逻辑是：先遍历实体列表生成nodes，同时用nodeMap记录节点名到节点对象的映射；然后遍历关联列表生成links，过滤掉那些源或目标不存在的边。我特意加了filter这一步，是为了防止脏数据产生悬空边。如果你在真实项目里发现关系图上有“牵着一根线却不显示节点”的情况，多半就是原始关联数据中引用了不存在的节点。

symbolSize的处理在这里用了简单映射：字段数越多，节点越大。你可以根据业务替换成更合适的指标，比如调用次数、金额、访问量。这里的小技巧是，symbolSize并不一定要和value绑定，你可以完全根据业务关注的核心指标来映射节点大小，这样视觉重点会更明确。

3.2 把转换后的数据灌进关系图配置

拿到转换后的数据，接下来就是创建图表实例并设置option。我这里给出一个完整的集成脚本，你可以直接复制后改数据源：

const chartDom = document.getElementById('graph-container'); const myChart = echarts.init(chartDom); fetch('./data.json') .then(res => res.json()) .then(rawData => { const graphData = buildGraphData(rawData.tables, rawData.relations); myChart.setOption({ tooltip: { trigger: 'item', formatter: params => { if (params.dataType === 'node') { return `节点：${params.name}<br/>分类：${params.data.category}`; } return `关系：${params.data.source} → ${params.data.target}`; } }, series: [{ type: 'graph', layout: 'force', data: graphData.nodes, links: graphData.links, roam: true, draggable: true, force: { repulsion: 150, edgeLength: 100 }, label: { show: true } }] }); });

这段代码用了fetch从data.json读取数据，然后再调用前面的buildGraphData函数做数据转换，最后通过setOption把关系图渲染出来。用fetch而不是直接在HTML里写数据，目的就是让数据文件可以独立更新，运行时不需要改代码。

tooltip.formatter在这里做了一点区分处理：当鼠标落在节点上时，展示节点名称和分类；当落在边上时，展示边的起点和终点。默认的tooltip遇到关系图会把节点和边的信息混在一起显示，区分之后可读性高得多，尤其是大屏场景下，浏览者经常需要快速确认一条数据流是从哪到哪的。

如果你在项目里用的是Vue或React，也可以把buildGraphData放进独立的工具模块，然后在组件的mounted或useEffect里调用。要注意的是，组件卸载时要记得调用myChart.dispose()，否则在切换页面时容易报“There is a chart instance already initialized on the dom”的警告，这个警告本身就是一种隐藏的内存泄漏，长时间跑大屏项目一定会遇到。

3.3 调整力导向参数，让关系图不挤作一团

很多刚接触关系图的同学把数据填进去之后，发现效果不好看，第一反应是换颜色、换大小。但实际上大部分观感问题出在force参数上。节点挤成一块、边密密麻麻分不清、节点飘到画布外，这些基本都是repulsion、edgeLength和gravity三个参数配比不对导致的。

我一般按节点数量来定参数：10到30个节点时，repulsion用80到120，edgeLength用80到130，效果最稳；50个以上节点时，repulsion就需要调到200以上，否则节点之间的排斥力不够，整张图会粘成一团。另外还有一个容易被忽略的layoutAnimation参数，把它设为false可以不渲染布局的动画帧，数据量大时能明显减少首屏等待时间。

force: { repulsion: 220, edgeLength: [50, 180], gravity: 0.15, friction: 0.6, layoutAnimation: false }

这里edgeLength用了一个数组[50, 180]，表示边的长度会落在50到180像素之间，比固定单值更自然。friction控制运动阻尼，值越小节点停止得越快；gravity控制在0.1到0.3之间比较安全，太大会把整个图压成一个圆饼，太小则会有节点跑到可视区外找不到。调参数时不要一次改多个变量，我通常是固定gravity和friction，只动repulsion和edgeLength，每次改完刷新看一眼分布，反复两三次就能调到理想状态。

在调参过程中如果发现某个节点始终游离在主图之外，那往往不是参数问题，而是这个节点只有一条很弱的连接，甚至没有连接。对于没有边的孤立节点，我建议要么在业务上确认它是否需要显示，要么单独设置它的x和y坐标，把它固定在画布角落。具体做法是在nodes数组的对应项里显式加上坐标字段，ECharts在layout非none时会优先尝试布局算法，但如果你设置的是layout: 'force'，手写的坐标通常会被覆盖。这种情况下，让这个节点带一个fixed: true字段，再给定x、y值，它就会固定在指定位置不被力导向算法推走。这个fixed字段在关系图调优期间非常好用，值得记下来。

4. 避坑指南：ECharts关系图从数据到渲染的5个深坑

4.1 节点图片不显示，只剩一个占位框

现象：给某个节点设置了symbol: 'image://images/user.png'，刷新页面后其他文字标签都在，但对应节点显示成一个小方框，图片没有渲染出来。

原因：ECharts的image://路径解析是基于当前HTML页面的URL，不是基于配置文件所在目录。如果你把图片放在images目录下，但HTML在子目录里打开，路径就会对不上；还有一种情况是用了相对路径./images/user.png，在服务根路径下没问题，一旦路由切换成二级路径，图片就失效了。

解决：先把图片路径改成绝对路径，从站点根目录开始写，比如/graph-project/images/user.png。如果是本地静态服务，确认图片实际存在且文件名大小写一致。最稳妥的方式是把图片转成base64字符串直接塞进symbol里，缺点是代码变长，但彻底杜绝路径问题。我一般只对几个关键节点用base64，其余节点用ECharts内置的圆形或矩形symbol。

4.2 节点名称重复导致边被连到错误的节点

现象：数据里有多个叫“汇总”的节点，关系图渲染后，有些边明明指向第二层的“汇总”，却连到了第一层的“汇总”上。

原因：ECharts关系图在解析links时，如果source或target传的是字符串，会按名称去匹配节点。名称存在重复时，匹配到的永远是第一个同名节点，所以边会错乱。这个错误很隐蔽，因为图表不会抛任何异常。

解决：在构造nodes时强制校验名称唯一性，或者在links里改用节点索引。我的习惯是用tableName_层级_编号这类复合名称来保证唯一，同时对原始数据做一次去重检查。你可以在buildGraphData函数里加一段逻辑：如果nodeMap中已存在同名节点，就给新节点名追加后缀，并同步修正关联边的指向。

4.3 关系图节点全部堆在左上角，布局失效

现象：打开页面后，所有节点挤在画布左上角，既没有力导向展开，也没有按坐标排列。

原因：series配置里layout字段缺失，或者layout写成了'none'却没有提供坐标。还有一种情况是数据量太大，力导向算法在短期内无法收敛，看起来就像堆在一起没动。

解决：确认layout: 'force'在配置中生效。如果数据量超过200个节点，把force.layoutAnimation设为false，并适当调大repulsion值，让模拟计算更快稳定。如果业务上节点位置是固定的，用layout: 'none'并且给每个节点都提供x、y坐标。混合场景下，可以对一部分节点设置fixed: true加坐标，其余节点仍然参与力导向布局。

4.4 关系图的边不显示箭头，方向不明

现象：关系图渲染出来后只有线条，没有箭头指向，看图表的人分不清数据流向是从A到B还是从B到A。

原因：ECharts关系图中的edgeSymbol默认是['none', 'none']，也就是边两端都不显示箭头。要显示有向箭头，需要配置edgeSymbol: ['none', 'arrow']，并且给lineStyle设置合适的宽度和颜色。

解决：在series里增加两个配置项：

edgeSymbol: ['none', 'arrow'], edgeSymbolSize: 8

这样边会在target端显示箭头。注意edgeSymbol数组的顺序是“起点符号”和“终点符号”，把箭头放在第二项才表示指向目标节点。当图里同时存在双向关联时，可以再配合lineStyle.curveness让两条方向相反的边错开，避免重叠成一条线。curveness取值在0到0.5之间，方向上相反的边设为同向曲率即可很好地分开。

4.5 图例和节点颜色对不上，明明设置了categories却全是一种颜色

现象：配置了categories数组，也给了每个节点category值，可图例只显示一项，节点颜色也一样。

原因：categories的顺序和索引没有和节点的category值对应上。比如categories数组定义了三类，但节点category写的是'存储层'而不是下标0、1、2。ECharts的关系图会把节点上的category字段和categories数组按索引匹配，传字符串时匹配不上就落到默认颜色。

解决：写一个映射函数，先把分类字符串转换成索引值。可以在转换数据时顺便处理：

const categoryIndex = {}; const categories = []; rawCategories.forEach((cat, i) => { categoryIndex[cat] = i; categories.push({ name: cat }); }); nodes.forEach(node => { node.category = categoryIndex[node.category]; });

这段代码把分类名字典和索引建立映射，再统一替换节点上的category为数字索引。这样图例就能正确显示多个分类，颜色也会按categories顺序生效。如果此时颜色仍然相同，去检查series的color数组是否被顶层配置覆盖，ECharts的color数组对graph的categories同样生效，并且itemStyle.color的优先级高于分类颜色。

5. 进阶用法：把关系图嵌进大屏，补上数据流和交互联动

关系图跑通只是第一步，真正放到大屏项目里，还得处理数据更新和联动效果。大屏上的关系图不是一次性渲染完就不管的，它要跟着过滤条件、轮询接口、定时任务实时变化。你想要的是，点击某个节点之后，旁边的柱状图跟着变化；或者每隔一分钟，后端推送新的关系数据，图自动刷新。

第一件要处理的事是动态更新数据。关系图的setOption不需要整个配置重写，只需要更新series.data和series.links：

myChart.setOption({ series: [{ data: newGraphData.nodes, links: newGraphData.links }] });

ECharts增量更新时，会保留之前的力导向模拟状态，新数据加入后节点不会突然全部重置位置，这个体验在大屏场景很关键。但如果数据变化特别大，我建议在setOption前加上myChart.clear()，否则旧节点残留，视觉上会让人觉得卡了或者错了。

第二件常做的事是节点点击联动。关系图不同于普通图表，它的数据结构天然适合做关联查询。点击一个节点，你可以拿它的name去查所有关联边，再dispatchAction高亮这些边。关键事件写法如下：

myChart.on('click', params => { if (params.dataType !== 'node') return; const nodeName = params.name; const relatedLinks = graphData.links.filter( link => link.source === nodeName || link.target === nodeName ); const neighborNames = new Set(); relatedLinks.forEach(link => { neighborNames.add(link.source); neighborNames.add(link.target); }); neighborNames.forEach(name => { myChart.dispatchAction({ type: 'highlight', name: name }); }); });

这段代码实现了最基础的邻接节点高亮：点击节点后，找出所有关联边，把邻居节点和边全部高亮，非邻居节点自动变暗。整个过程中name是节点标识，所以又一次回到那个坑——节点名称必须唯一。在真实大屏开发里，我通常把所有节点的主键（比如设备ID、表名）作为name，展示文案放大到label.formatter里去，这样既保证唯一性，又能显示友好名称。

第三件要处理的是配置里的自适应。大屏的分辨率不固定，关系图如果写死容器的宽高，换一个屏幕就失效。常见做法是监听窗口变化并调用resize：

window.addEventListener('resize', () => { myChart.resize(); });

不是所有大屏项目都有窗口缩放，更多情况是不同信号源输出不同分辨率。针对这种情况，我的习惯是容器div设置百分比宽高，图表初始化时再读取一次容器尺寸，确保首次运行在非标准分辨率下也能正确铺满。

最后说一个对我自己很有用的习惯。每次启动一个带关系图的新项目，我都会强制走一遍固定流程：先写buildGraphData做数据转换和节点去重校验，再渲染一个最小配置确认图能出来，然后逐个加tooltip、legend、edgeSymbol这些辅助配置，最后才调力导向参数。这四步每一步都做一次页面刷新确认，而不是一口气写完再排错。因为关系图的报错机制很不友好，很多配置写错只会在控制台打一行警告，图上照样渲染，但功能就是不对。从那以后，我每接到一个关系图需求或者复用一个现成工程，都会强制走一遍这个四步流程，把“能跑”和“能用”分开来验证。

希望这个拆解思路，以及这份关系图20里沉淀的配置和数据格式，能帮你少走几段弯路。对我来讲，最值得的从来不是把图渲染出来，而是知道它为什么这样渲染、改哪里才能让业务真正读得懂这张图。

本文还有配套的精品资源，点击获取