企业官网建设流程全解析

做数据大屏或者汇报材料的人，大概率都遇到过同一个尴尬：堆叠柱状图的数据逻辑明明很清晰，但视觉上就是"平"——几层颜色一叠，看起来像一块色块拼图，领导扫一眼问"这是柱子还是面积图"。于是很自然想到给柱子加上圆柱质感，做成 3D 立体圆柱堆叠柱状图。这件事在 ECharts 里有三条完全不同的实现路径，代价差得很远，而绝大多数人第一反应会去搜 echarts-gl，结果引入一个几百 KB 的额外依赖，换来的却是掉帧的动画和点不准的 tooltip。

我这几年做过不少这类大屏，最后稳定落地的方案跟 gl 一点关系都没有，全靠 ECharts 自带的bar和pictorialBar两个系列拼出来。核心思路说出来特别朴素：一根圆柱在二维平面上就是一个矩形加几个椭圆，柱身交给bar去累加，顶盖交给pictorialBar去定位，两者用barGap: '-100%'强行重叠在一起。下面我把这套做法从选型、几何拆解、数据组织到踩坑记录完整走一遍，适合已经会用 ECharts 基础配置、想在大屏上要一点立体感但又不想为此付出性能代价的前端同学习参考。

1. 三种能做出"3D圆柱堆叠"的路子，先分清代价

先把可选方案摆到台面上。很多人在这一步就走了弯路，不是因为技术难，而是因为搜索关键词一撞，满屏都是bar3D、grid3D的示例，看着确实立体，就一头扎进去了。实际上这三条路线的适用场景完全不同，选错了后面全是补丁。

1.1 方案一：bar 打底 + pictorialBar 盖顶，纯二维配置拼出立体感

这是我最推荐、也是实际项目里用得最多的一条路。bar系列负责真正的数据可视化工作——堆叠、坐标映射、数值计算、tooltip 命中，全都是 ECharts 原生能力，一行都不用自己写。pictorialBar（象形柱图）负责纯装饰，它的作用是在指定的数值位置画一个图形符号，符号可以是内置的circle、rect、ellipse，也可以是自定义的 SVG path。

关键在于pictorialBar有一个symbolPosition属性，取值'start'、'end'、'center'，默认是'end'，意思是"把图形画在这个数值对应的位置顶端"。配合symbolSize控制椭圆的宽高、symbolOffset做位置微调，就能让一个椭圆正好压在每一段柱子的交接线上，形成圆柱被"切开"的视觉效果。

这条路的额外依赖是零，echarts.js一个文件搞定。文字标签、tooltip、图例、点击事件、数据缩放，全部原生支持，你不需要为任何一个基础功能写兼容代码。代价是它只是"伪 3D"——柱子的侧面没有真正的透视，只是靠横向渐变假装出圆弧。但在大屏这种观看距离动辄两三米的场景下，这个差别基本没人能看出来。

1.2 方案二：echarts-gl 的 bar3D，真三维但代价不小

echarts-gl提供了bar3D系列和grid3D坐标系，走的是 WebGL 渲染。配置大概长这样：一个grid3D定义三维网格，一个xAxis3D/yAxis3D/zAxis3D，然后bar3D里设stack: 'total'做堆叠，bevelSize控制柱体的倒角大小。

倒角这个参数是bar3D做圆柱的唯一抓手——把bevelSize调到接近柱宽的一半，棱角会被磨得很圆，视觉上接近圆柱。但它本质上是"倒角的长方体"，不是圆柱，八个角始终存在，只要视角偏一点就会露馅。

更麻烦的是配套功能。WebGL 场景里的文字标签需要单独用label转成贴图，清晰度和排版都不如二维；tooltip 需要射线检测拾取，手感发飘；dataZoom、legend联动在三维坐标系里基本不能用。而且 WebGL 在拼接大屏、低配一体机上的帧率表现很不稳定，一旦动画播放过程中掉到 20 帧以下，整个页面的观感就崩了。

1.3 方案三：custom 系列自己画路径

custom系列允许你接管渲染函数renderItem，拿到坐标系信息和数据，然后用graphic的path自己一段一段画。自由度最高，圆柱、圆台、任意形状都能画，渐变、描边、光影全部可控。

但这是把简单问题复杂化。renderItem里要自己处理正向/负向数据、堆叠累计、坐标转换、命中区域、hover 高亮、动画过渡，每一样都是工作量。除非你的图形确实超出常规柱状图的范畴（比如要画真实的透视投影），否则不值得。我之前在一个需要"稍微带点透视"的项目里试过，光是把 hover 的命中矩形对齐就调了半天，最后还是退回了方案一。

1.4 三条路线的横向对照

结论很清楚：只要你的诉求是"在汇报里让柱子看起来有立体感"，方案一足够；只有当项目明确要求可旋转、可拖拽的真三维场景，才考虑 gl。

2. 一根圆柱的解剖：为什么必须拆成"柱身 + 顶盖"两层

定下方案之后，很多人卡在第二步——照着示例把pictorialBar塞进配置里，出来的东西却像一根被拉长的胶囊，或者盖子跟柱子错开半截。问题出在没有搞清楚二维平面上"圆柱"到底由哪几个几何元素构成。

2.1 正交投影下，圆柱只暴露三个面

想象你站在一张桌子正前方看一个竖起来的易拉罐，不做俯视也不做仰视。你看到的其实是：中间一个矩形（圆柱侧面），顶上半个椭圆（顶盖被压扁的透视），底下半个椭圆（底盖，通常被桌面挡住）。这就是全部。

所以一根看起来立体的圆柱，需要三个元素：柱身矩形、顶部椭圆、底部椭圆。而在堆叠场景里，底部椭圆永远被下层柱子遮住或者跟背景贴在一起，实际只需要画柱身和顶盖两样东西。

理解这一点之后，bar和pictorialBar的分工就顺理成章了：bar画那个矩形，pictorialBar用ellipse符号画那个顶盖椭圆。两个 series 数据一致、位置重叠，视觉上就合成了一根圆柱。这一步想通了，后面全是参数微调。

2.2 椭圆的扁度决定"这是圆柱还是药丸"

顶盖椭圆的高度是整个效果里最敏感的一个参数。它的取值应该跟柱宽挂钩，而不是拍脑袋写死一个数字。

我的经验区间是：椭圆高度 ≈ 柱宽 × 0.20 ~ 0.28。柱宽 40px 的话，椭圆高度取 8px 到 11px 之间。低于 0.15，椭圆扁成一条线，远看根本看不出是圆柱的顶，立体感丢失；高于 0.32，椭圆过于饱满，整根柱子会像一颗竖着的胶囊药丸，而且椭圆的上下弧会啃掉太多柱身高度，数据对比被削弱。

还有一点容易被忽略：椭圆的宽度必须等于柱宽。pictorialBar的symbolSize是[宽, 高]两个值，很多人只调高度忘了宽度，或者柱宽改了椭圆没跟着改，结果就是盖子比柱子宽出一圈，像给柱子戴了顶帽子。

symbolOffset也要配合着设。椭圆默认是居中对齐在数值线上的，也就是说一半在柱子上方、一半在柱子里。这其实正好是我们想要的——顶盖露在上面一半，圆柱的"厚度感"就出来了。但有些人为了让它完全露出来，把symbolOffset往负方向调了一整个椭圆高度，结果顶盖和柱身之间出现一道缝。正确的是[0, -ellipseHeight / 2]，让椭圆中心正好落在柱顶分界线上。

2.3 堆叠柱的核心视觉：每一层交界都要有一圈顶盖

这是堆叠圆柱和单根圆柱最大的区别，也是很多人做出来"不像堆叠"的原因。

单根圆柱只需要最顶上有一个椭圆。但堆叠柱是多段接起来的，如果只在最顶端画一个椭圆，下面几段的交界处就是一条硬邦邦的直线，视觉上它还是一根普通柱子，只是顶端圆了一下。

真正让堆叠产生"叠罗汉"感的关键，是每一段的上沿都有一圈椭圆弧。想象你把几个不同颜色的圆饼摞起来，从侧前方看过去，每一层的上表面边缘都会露出一道弧线，颜色还比侧面亮一点。这才是堆叠圆柱的灵魂。

所以 series 的数量是 2N，不是 N+1。3 个数据系列，就要配 3 个bar加 3 个pictorialBar，每个pictorialBar的顶盖落在对应那一层的累计高度上。这个"2N"的结构是后面所有配置的骨架，先记住。

3. bar 负责累加、pictorialBar 负责定位，两套数据必须分开算

到了配置阶段，第一个真正的坑就来了：bar的堆叠靠stack自动累加，而pictorialBar如果也设stack，会参与同一套累加逻辑，数字就翻倍了。这两类 series 的数据必须走两条不同的计算路径。

3.1 stack 只解决"谁叠在谁上面"，不解决"盖在哪"

先把stack说清楚，因为这里的概念混淆特别普遍。

stack: 'total'的作用是告诉 ECharts：这几个 series 的数值不要各自从 0 开始画，而是累计叠加。系列 A 值是 10，系列 B 值是 20，那么 A 从 0 画到 10，B 从 10 画到 30。ECharts 内部会自动维护这个累加过程，你传的 data 永远是原始值，不需要自己算累计。

但pictorialBar不吃这套。它的symbolPosition: 'end'定位逻辑是"画在这个 series 该数据点对应的数值高度上"。如果这个 series 也设了stack，它会跟着其它 series 一起累加，椭圆的落点就跑到别的地方去了。

正确做法是：bar设stack，pictorialBar不设stack，并且pictorialBar的 data 传累计值。这样累加只发生一次（在bar这边），椭圆的定位则完全由你掌握的累计值决定，两边各司其职，互不干扰。

3.2 累计值数组的生成

真实场景里几乎不会只有一根柱子，通常是"12 个月 × 3 个系列"这种结构。累计值就必须按类目逐个算，不能整列累加。

我一般写一个二维的累加函数，输入是seriesData[系列索引][类目索引]的二维数组，输出同结构的累计值：

function accumulate(seriesData) { const result = []; for (let s = 0; s < seriesData.length; s++) { result[s] = []; for (let c = 0; c < seriesData[s].length; c++) { const prev = s === 0 ? 0 : result[s - 1][c]; result[s][c] = prev + seriesData[s][c]; } } return result; }

这个函数看着简单，但有个容易写错的地方：prev要取的是上一层同一个类目位置的累计值，也就是result[s - 1][c]，而不是result[s][c - 1]。写成后者就变成横向累加了，柱子会一路狂涨。

生成之后，第 s 个pictorialBar的data就用result[s]。这样第 s 层的顶盖正好落在第 s 层柱子的上沿。

提示：如果你的数据里存在空洞（null），累加时会得到NaN，整根柱子都画不出来。传数据前先做一次null -> 0的兜底清洗，或者在累加函数里判断isFinite。

3.3 颜色分层：越靠上的分段越要压暗或提亮

堆叠柱天然有个问题：几层颜色叠在一起时，如果明度接近，交界线会糊成一片，加了顶盖也看不出分层。

我的处理方法是给每一层单独算一组颜色：柱身颜色逐层做轻微的明度递进，顶盖颜色统一比对应柱身亮一档。用 ECharts 内置的echarts.color.lift就能做，第一个参数是颜色字符串，第二个是提亮幅度（0 到 1）：

const bodyColor = echarts.color.lift(baseColor, index * 0.06); const capColor = echarts.color.lift(baseColor, 0.32);

lift幅度控制在 0.05 到 0.08 之间逐层递进，视觉上就有"从下往上受光逐渐变强"的层次感，但又不至于让颜色跑偏到另一个色系。顶盖用 0.3 左右的提亮，跟柱身拉开明确差距，椭圆弧才能被眼睛抓住。

需要注意lift是往白色方向混，饱和色（比如正红、正蓝）提亮之后容易发粉发灰。如果品牌色卡得很死，宁可改用echarts.color.modifyHSL只调亮度通道，保持色相一致。

4. 一份能直接跑起来的配置骨架

理论讲完，落地成代码。下面这套结构我在好几个项目里复用，改一下数据和配色就能直接用。

4.1 数据结构和 series 工厂

先定义基础数据，两个数组，一个类目、一个二维系列值：

const categories = ['1月', '2月', '3月', '4月', '5月', '6月']; const seriesNames = ['基础层', '中间层', '峰值层']; const baseColors = ['#3a7bd5', '#00b894', '#f5a623']; // seriesData[系列][类目] const seriesData = [ [12, 18, 15, 22, 19, 26], [8, 14, 20, 16, 22, 18], [6, 9, 12, 10, 15, 13] ];

然后是 series 生成函数，把颜色、累加、顶盖尺寸一次性算好：

function buildSeries(seriesData, seriesNames, baseColors, barWidth) { const capH = Math.round(barWidth * 0.24); // 顶盖椭圆高度 const totals = accumulate(seriesData); const series = []; seriesData.forEach((row, i) => { // 柱身 series.push({ name: seriesNames[i], type: 'bar', stack: 'total', barWidth: barWidth, barGap: '-100%', barCategoryGap: '38%', z: 2, itemStyle: { color: makeCylinderGradient( echarts.color.lift(baseColors[i], i * 0.06) ) }, emphasis: { focus: 'series' }, data: row }); // 顶盖 series.push({ name: seriesNames[i] + '__cap', type: 'pictorialBar', symbol: 'ellipse', symbolSize: [barWidth, capH], symbolOffset: [0, -capH / 2], symbolPosition: 'end', barGap: '-100%', barCategoryGap: '38%', z: 3, silent: true, tooltip: { show: false }, itemStyle: { color: echarts.color.lift(baseColors[i], 0.32), borderColor: echarts.color.lift(baseColors[i], 0.55), borderWidth: 1 }, data: totals[i] }); }); return series; }

注意几个细节：pictorialBar的barGap和barCategoryGap必须跟bar保持一致，否则两者会横向错开；silent: true关掉交互，避免鼠标移上去时顶盖抢走高亮；tooltip: { show: false }把它从提示框里摘出去，否则每个类目会多出三条无意义的记录。

4.2 坐标轴、grid、legend 的连带调整

加了顶盖之后，柱子的实际视觉高度会超出bar的数值范围——因为最顶端的椭圆往上冒了capH / 2。如果 y 轴max刚好卡在最大值上，顶盖会被裁掉。

处理办法是给 y 轴留出余量，用max函数按比例放大，或者干脆用scale: true让 ECharts 自己算，再配boundaryGap: [0, '15%']：

yAxis: { type: 'value', boundaryGap: [0, '12%'], splitLine: { lineStyle: { color: '#eef1f6', type: 'dashed' } }, axisLabel: { color: '#8a94a6' }, axisLine: { show: false }, axisTick: { show: false } }

图例这块必须显式指定data。因为 series 数组里有 6 个条目，其中 3 个是__cap后缀的顶盖，如果不管，图例里会多出一半的重复项：

legend: { data: seriesNames, // 只写原始系列名 top: 8, itemWidth: 12, itemHeight: 12, icon: 'circle' }

legend用data显式声明之后，ECharts 只会为这三个名字生成图例项，点击时的系列开关也只会作用于同名的bar系列——顶盖是silent的，不会跟着响应对应关系，所以需要额外处理：监听legendselectchanged，手动开闭对应的__cap系列。

4.3 顶部总数值标签挂在哪一层

大屏上一般要在柱顶标一个总数。这个标签挂在最后一层的bar上就行，用label配置：

// 仅最后一层 bar 加 label { label: { show: true, position: 'top', distance: capH + 8, // 让开顶盖 color: '#2c3e50', fontSize: 13, fontWeight: 600, formatter: (p) => totalAt(p.dataIndex) } }

distance一定要比capH大，否则标签会压在椭圆上。formatter里返回的是该类目的总和，需要另算一个数组存着，不能直接用p.data——那是当前层的值。

如果想让数值带千分位或者单位，在formatter里统一处理，不要用valueFormatter，因为后者在不同 ECharts 版本里的行为有差异，直接写formatter函数最稳。

5. 实测翻车记录：这几个坑我挨个踩过

配置看起来齐了，实际跑起来还是会出问题。下面这几个是我调试过程中真实撞上的，排查链条完整记下来，遇到同类现象可以直接对照。

5.1 pictorialBar 抢柱位：barGap 与 barCategoryGap 的联动

第一次跑出来的时候，顶盖椭圆整体往右偏了半个柱宽，跟柱身完全错开，看起来像是两根不同位置的柱子叠在一起。

原因在于 ECharts 的柱状布局逻辑：同一坐标系下的多个 bar/pictorialBar 系列，默认会并排分配宽度，各自占一个位置。即使pictorialBar的符号很小，它依然会被分配到一个完整的"柱位"。

解决办法是把所有 series 的barGap设为'-100%'，强制它们互相重叠。但光设这个还不够——barGap是相对柱宽计算的，如果各系列的barWidth或barCategoryGap不一致，重叠之后仍然会错位。所以两个参数必须在所有 series 上保持完全相同的值。

排查这类问题的通用手法：把barWidth临时设成一个显眼的大值（比如 80），配一个高饱和的背景色，一眼就能看出哪个系列飘了。

5.2 数值为 0 的残影

数据里出现 0 的时候，bar的高度是 0，但pictorialBar依然会在那个位置画一个完整的椭圆。结果就是柱子的交界处堆着一个孤零零的、悬空的椭圆片，看起来像是漏渲染了。

这不是 bug，pictorialBar的行为就是这样——它的symbolSize跟数据值无关，只要有数据点就画符号。

处理方式有两种。一种是在生成顶盖 data 的时候把 0 值替换成'-'（ECharts 会当作无数据处理，不渲染符号）：

data: totals[i].map(v => (v > 0 ? v : '-'))

另一种是保留数值但用itemStyle.opacity的函数形式做条件判断：

itemStyle: { opacity: (p) => (p.value > 0 ? 1 : 0) }

后一种能保留动画时的过渡，前者更彻底。我一般用后者，因为切换数据源重新setOption时，前者会出现符号突然出现/消失的跳变。

5.3 resize 之后柱宽变了顶盖没变

这个问题第一次看到会很懵：浏览器窗口从宽屏拖到窄屏，柱身自动变窄了，但顶盖椭圆还是原来那么宽，像给柱子撑了一把伞。

根源在于barWidth如果你写的是像素数字，ECharts 会严格遵守；而pictorialBar的symbolSize也是像素值，两者都不会自适应。窗口变化时，barCategoryGap按比例算出来的柱宽变了，但symbolSize里的数字没变。

彻底的解法是不写死，改成运行时计算 + resize 监听：

function calcBarWidth(chart, categoryCount) { const w = chart.getWidth(); const per = w / Math.max(categoryCount, 1); return Math.max(16, Math.min(52, Math.round(per * 0.32))); }

然后在resize事件里重新计算并setOption：

window.addEventListener('resize', () => { const bw = calcBarWidth(chart, categories.length); chart.setOption(buildSeries(seriesData, seriesNames, baseColors, bw), { replaceMerge: ['series'] }); });

replaceMerge: ['series']这个参数很关键。如果直接setOption传新 series，ECharts 默认是合并模式，新旧系列会按照索引配对合并，symbolSize确实会更新，但如果你中途增减了系列数量，合并模式会留下残余的旧系列。用replaceMerge明确指定替换整个 series 数组，能避免这类幽灵系列。

5.4 tooltip 和 legend 被顶盖污染

前面提过pictorialBar要设tooltip: { show: false }，但实践中有个版本差异：在trigger: 'axis'模式下，某些 ECharts 5.x 的小版本对 series 级tooltip.show的响应不完整，提示框里依然会出现顶盖条目。

保险做法是在formatter里做一次名字过滤：

tooltip: { trigger: 'axis', axisPointer: { type: 'shadow', shadowStyle: { color: 'rgba(58,123,213,0.06)' } }, formatter: (params) => { const list = params.filter(p => !String(p.seriesName).endsWith('__cap')); if (!list.length) return ''; const head = `<div style="font-weight:600;margin-bottom:6px">${list[0].axisValue}</div>`; const rows = list.map(p => `<div style="display:flex;justify-content:space-between;gap:16px"> <span>${p.marker}${p.seriesName}</span> <span style="font-weight:600">${p.value ?? '-'}</span> </div>` ).join(''); const total = list.reduce((s, p) => s + (Number(p.value) || 0), 0); return head + rows + `<div style="border-top:1px solid #eef1f6;margin-top:6px;padding-top:6px; display:flex;justify-content:space-between;gap:16px"> <span>合计</span><span style="font-weight:700">${total}</span> </div>`; } }

顺便把合计也拼进去，大屏上不需要用户自己心算。

6. 让圆柱更像圆柱的几处打磨

基础效果跑通之后，剩下的差距全在细节里。同样的结构，加不加下面这几处处理，观感能差出一个档次。

6.1 柱身横向渐变的光源方向

纯色柱身永远是"扁"的，圆柱感来自侧面的明暗过渡。给柱身的color换成横向线性渐变，从左到右走"暗—亮—亮—暗"四个色标：

function makeCylinderGradient(base) { const dark = echarts.color.lift(base, -0.22); const light = echarts.color.lift(base, 0.34); return new echarts.graphic.LinearGradient(0, 0, 1, 0, [ { offset: 0.0, color: dark }, { offset: 0.32, color: light }, { offset: 0.62, color: light }, { offset: 1.0, color: dark } ]); }

LinearGradient的四个参数是(x0, y0, x1, y1, colorStops)，0,0,1,0表示从左到右。高光的两个色标放在 0.32 和 0.62 之间，而不是正中间 0.5——这是刻意的，光源稍微偏左会让柱子看起来更自然，正中间的高光反而像塑料管。

还有一个隐蔽的坑：所有柱子的高光方向必须一致。如果不同系列用了不同的渐变角度，堆在一起会像几根来自不同光源的柱子拼贴，视觉上非常别扭。所以makeCylinderGradient里角度写死，只让基色变化。

6.2 顶盖描边与高光

顶盖椭圆如果只是纯色填充，跟柱身高光区的明度太接近，圆弧边界会被吃掉。加一圈比填充色更亮的描边，边线立刻清晰：

itemStyle: { color: echarts.color.lift(base, 0.32), borderColor: echarts.color.lift(base, 0.58), borderWidth: 1, shadowBlur: 6, shadowColor: 'rgba(0,0,0,0.06)', shadowOffsetY: 1 }

shadowBlur那一点点投影很有用，它让顶盖产生"浮在柱子上方"的错觉，立体感会再强一档。但幅度一定要小，blur超过 10 就会糊成一团脏色，尤其在大屏上放大后特别明显。

另外，如果想让柱子有"半透明玻璃"的质感，可以把柱身渐变的色标 opacity 调低到 0.8 左右，顶盖保持高不透明。半透明柱身会透出背后的网格线，看起来更有玻璃感，但网格线如果太密就会显得杂乱，需要把splitLine的透明度也降下来配合。

6.3 大屏上的入场动效与降级

堆叠圆柱的入场动画默认是从底部一起长出来的，几个系列同时动，观感有点糊。想让层次分明，可以给每个系列加animationDelay，按层错开：

animationDelay: (idx) => idx * 80, animationDuration: 700, animationEasing: 'cubicOut'

注意animationDelay是按数据索引回调的，不是按系列索引。所以在同一个 series 内部，12 根柱子会依次长出来，形成从左到右的波浪效果。这个在汇报场景里特别好用，比一次性全部弹出有节奏感。

降级这块也要提前想。如果页面同时挂着七八个图表，或者跑在拼接大屏的播控机上，动画是主要的性能开销来源。我的做法是加一个运行时开关，检测到navigator.hardwareConcurrency小于 4 或者页面不可见时，直接把animation关掉：

const lowPower = (navigator.hardwareConcurrency || 4) < 4; const option = { animation: !lowPower, // ... };

关掉动画之后，由于我们用的是纯 Canvas 2D 渲染，几个堆叠圆柱图同屏跑满 60 帧毫无压力，这一点是 gl 方案完全比不了的。

我个人在做这类图表时最深的体会是：先想清楚"观者能看到什么"，再决定"技术要做什么"。大屏上没人会把脸贴到屏幕上去分辨这是不是真三维，他们看到的只是一根有明暗、有顶盖、有层次的柱子。为了这点观感去引入一个 WebGL 依赖，换来的是加载时间变长、交互手感变差、低配设备上不可控的掉帧，这笔账怎么算都不划算。

唯一的例外是场景本身要求可旋转、可拖拽的真三维探索，那时候bar3D才有它的位置。但那已经是另一个产品形态了，跟"把一根柱子画得好看点"完全是两件事。