做设备监测平台前端看板的那段时间，我几乎每周都会碰到同一个需求：光把一条折线图画出来根本不够，还得把“正常范围”用一块半透明区域标出来。比如空压机出口温度监控，不仅要看温度随时间的走势，还要一眼看出哪些时段越过了 70°C 告警线、哪些时段又跌到 30°C 以下。落到 ECharts 上，这就是典型的折线图上下限区域展示——主折线反映真实数据，两条阈值线划定边界，阈值之间填充半透明色带，让越界信息被视觉直接放大。这篇文章就把我实际落地这套效果的完整方案、代码和踩过的坑写出来，适合做监控大屏、工业看板、数据报表的朋友参考。

1. 为什么需要“上下限区域”：从一个监控看板的需求说起

先明确一个观点：上下限区域展示不是“花哨”，而是监控类图表的刚需。没有区域色的折线图，用户只能靠 y 轴刻度去猜“这个值离告警线多远”；有了区域色带，人的视觉能直接在面积层面上感知“是否越界，越了多少”，判断速度快一个量级。

1.1 典型业务场景

我做过的项目里，这类需求集中在四个场景：

• 设备状态监控：温度、压力、振动幅值都有安全运行区间，超出即触发告警。空压机温度就是最直接的例子。
• 库存与水位管理：安全库存有上下限，低于下限要补货，高于上限要考虑滞销风险。
• 业务指标波动：订单量、客单价在正常情况下会有一个预期波动范围，超出范围说明运营动作或外部环境发生了异常。
• 质量检测：产品关键参数的规格界限（USL/LSL），SPC 控制图里经常要画均值线的 ±3σ 通道，本质上也是上下限区域。

这些场景的共同点是：阈值是确定的，但数据是动态的，且是否越界才是用户最关心的信息。如果只把上下限画成两条虚线，其实也能用，但视觉冲击力和信息传达效率远不如一块彩色区域。

1.2 需求拆解：不止是“画两条线”

把这类需求拆开，至少包含三层：

1. 数据层：主指标序列，通常是一个数组，可以是固定时间段的历史数据，也可以是实时滚动流。
2. 阈值层：上限序列和下限序列。它们可以是固定常量（比如温度 30~70°C），也可以是动态计算的（比如移动平均 ± 一定比例，或者统计模型的预测区间）。阈值是动态还是静态，直接决定技术方案怎么选。
3. 视觉层：主折线要突出，上下限线要弱化但不能看不清，上下限之间的填充区域要半透明、不遮挡折线和数据点，同时还要保证 tooltip 悬浮时能同时看到“当前实际值、上限、下限”三个关键数字。

前三层如果只做静态展示，ECharts 自带的markArea勉强够用；一旦上下限要随数据滚动、随业务实时计算，就必须用自定义系列加堆叠的思路来做。下面详细对比。

2. 三种实现思路的取舍：markArea、自定义系列+stack、visualMap

我见过很多同事第一次做这个需求时，第一反应都是去搜markArea怎么用，结果做到一半发现矩形区域跟不上数据曲线，又回来重写。所以先把方案对比放前面，这会帮你少走弯路。

2.1 方案 A：markArea 标记矩形区域

ECharts 官方给markArea的定位是“图表标注”，最常见用途是给某个时间段打上高亮背景。比如标出“故障发生时段”“促销活动时段”：

markArea: { silent: true, itemStyle: { color: 'rgba(255, 0, 0, 0.1)' }, data: [ [ { xAxis: '2024-06-01 10:00' }, { xAxis: '2024-06-01 11:00' } ] ] }

优点是非常简单，几行代码就能完成。但缺点也很明显：

• 它是矩形，上下边界只能是水平直线，无法贴合一条波动的阈值曲线。
• 如果上下限是动态计算的，每次 setOption 都得重新生成整个 markArea data，维护成本高。
• 多个上下限区间叠加时，配置会变得很臃肿。

markArea适合的场景是：上下限固定为常量、且只想展示“超出某个区间”的矩形背景，而不是让区域跟某条阈值曲线走。在我遇到的监控需求里，这个条件很少满足，所以它更多作为辅助手段，而不是主方案。

2.2 方案 B：自定义系列 + stack 堆叠填充（推荐）

这是目前实现“动态上下限区域”最主流的方案。核心思路是：用两个辅助系列把上下限之间的区域“挤”出来。

具体做法是构建三个辅助数据序列：

• lower：下限数组。
• upper：上限数组。
• diff：上限与下限的差值数组（diff[i] = upper[i] - lower[i]）。

然后在 ECharts series 里：

• lower系列设置stack: 'band'，用来画下限虚线。
• diff系列也设置stack: 'band'，不画线，只画areaStyle半透明填充。因为堆叠的原因，diff系列的填充区域会被“托”在lower系列之上，于是填充区域自然落在下限与上限之间。
• upper系列可以不设 stack，单独画一条件虚线，这样 tooltip 悬停时显示的是真实上限值，而不是差值。

用个生活类比帮助理解：两个助手踩在同一根桩子上，lower先站到底部，diff再踩着lower的肩膀站上去。diff的身形被撑在 35 到 85 之间，它身上那块半透明斗篷，就是我们要的上下限区域。桩子一抽（隐藏 lower 系列），斗篷就会掉到地上——这个坑后面章节专门讲。

这套方案的优点是：

• 上下限完全由数据驱动，动态计算、滚动刷新都很好做。
• 区域边缘天然跟随阈值曲线，想要“喇叭口”形状的带宽也画得出来。
• legend 和 tooltip 都高度可控。

2.3 方案 C：visualMap 分段视觉映射

visualMap通常用在热力图、散点图上，也能用在折线图上做分段配色。它解决的是“超不超限”的另一个维度：让超出上限或跌破下限的线段自动变红，而不是画区域。

visualMap: { type: 'piecewise', pieces: [ { gt: 85, color: '#ee6666' }, { lte: 85, gt: 35, color: '#5470c6' }, { lte: 35, color: '#ee6666' } ] }

它很适合做异常点的强调，但它无法画出上下限之间的填充色带，也不能表达“阈值本身在哪里”。所以我的建议是：visualMap 是辅助增强，不是替代方案。真实项目中完全可以把方案 B 和方案 C 组合：区域色带表示“安全范围”，线段画成“正常蓝 + 越界红”，这样信息量最完整。

2.4 三个方案怎么选

我的结论很明确：做监控看板优先选择方案 B，把 visualMap 作为可选项加进去。接下来的完整实现也基于方案 B。

3. 完整实现：一个可复制的上下限区域折线图

这里直接给一套可以跑起来的完整代码。我以空压机出口温度为例，模拟 30 个半小时刻度，实际值在 35~85°C 区间内波动，超过这个区间就会被色带和虚线边界凸显得非常清楚。

3.1 完整 HTML 与 ECharts 配置

<!DOCTYPE html> <html lang="zh-CN"> <head> <meta charset="UTF-8" /> <title>ECharts 折线图上下限区域展示</title> <script src="https://cdn.jsdelivr.net/npm/echarts@5.5.0/dist/echarts.min.js"></script> <style> #chart { width: 100%; height: 480px; } </style> </head> <body> <div id="chart"></div> <script> const chart = echarts.init(document.getElementById('chart')); // 生成模拟数据：30 个时间点，温度在 35~85 之间波动 function genData(count) { const times = []; const actual = []; const lower = []; const upper = []; for (let i = 0; i < count; i++) { const hour = Math.floor(i / 2) + 8; const minute = i % 2 === 0 ? '00' : '30'; times.push(`06-01 ${String(hour).padStart(2, '0')}:${minute}`); const v = 60 + Math.sin(i / 4) * 12 + (Math.random() * 8 - 4); actual.push(Math.round(v * 10) / 10); lower.push(35); upper.push(85); } // 关键：diff 数组是 upper 和 lower 的差值 const diff = actual.map((v, i) => upper[i] - lower[i]); return { times, actual, lower, upper, diff }; } const data = genData(30); chart.setOption({ tooltip: { trigger: 'axis', axisPointer: { type: 'cross' }, formatter: function (params) { // 过滤掉‘区间’系列，只展示真实的上限、下限、实际值 const list = params.filter(p => ['实际值', '上限', '下限'].includes(p.seriesName)); let html = `${list[0].axisValue}<br/>`; list.forEach(p => { html += `${p.marker}${p.seriesName}：${p.value} °C<br/>`; }); return html; } }, legend: { data: ['实际值', '上限', '下限'], selectedMode: false // 防止点击图例隐藏堆叠基准系列 }, grid: { left: 60, right: 30, top: 60, bottom: 60 }, xAxis: { type: 'category', data: data.times, boundaryGap: false }, yAxis: { type: 'value', min: 0, max: 100, axisLabel: { formatter: '{value} °C' } }, dataZoom: [{ type: 'inside' }, { type: 'slider' }], series: [ { name: '下限', type: 'line', stack: 'band', // 下限作为填充区域的底部基准 data: data.lower, symbol: 'none', lineStyle: { type: 'dashed', color: '#ff9800', width: 1 } }, { name: '区间', type: 'line', stack: 'band', // 区间系列堆叠在‘下限’之上，areaStyle 才会从下限开始填充 data: data.diff, symbol: 'none', lineStyle: { color: 'transparent' }, areaStyle: { color: 'rgba(255, 152, 0, 0.15)' }, tooltip: { show: false } // 不在 tooltip 中暴露差值 }, { name: '上限', type: 'line', data: data.upper, symbol: 'none', lineStyle: { type: 'dashed', color: '#ff9800', width: 1 } }, { name: '实际值', type: 'line', data: data.actual, symbol: 'circle', showSymbol: false, lineStyle: { color: '#5470c6', width: 2 } } ] }); </script> </body> </html>

3.2 核心机制：为什么这样设置 stack

这段代码最容易让人困惑的就是stack到底干了什么。ECharts 的堆叠逻辑是：同一坐标系里，stack名称相同的系列会按顺序累加数值。

• lower系列第 i 个点绘制在 y = 35 的位置；
• diff系列第 i 个点累加之后绘制在 y = 35 + 50 = 85 的位置；
• 由于diff系列开了areaStyle，填充区域就落在“35 高度到 85 高度”之间。

如果去掉lower系列的stack: 'band'，diff系列就会以 y = 0 为基准，区域变成从 0 一直填到 85，整个图下半部分全变成色块，完全不是我们想要的效果。这就是为什么lower和diff必须绑在同一个 stack 组里。

3.3 为什么不把上限线也塞进同一个 stack

有的教程会直接把upper系列也放进 stack，然后把upper的 data 设置为diff值。这种写法图看起来一样，但 tooltip 里显示的是差值，而不是真实的上限值。用户看到 tooltip 里写着“上限：50”，心里一定懵：“上限不是 85 吗？”

所以我坚持把upper单独设成一个不参与 stack 的 series，数据直接存真实上限。这样：

• 图上的虚线位置正确；
• tooltip 数值正确；
• legend 里的“上限”“下限”含义清晰。

代价只是多一个 series，但对可维护性来说是值得的。

3.4 动态阈值怎么改

如果业务里上下限不是固定常量，而是动态算出来的，只需把genData里的lower和upper改成计算逻辑。比如取最近 5 个点的移动平均 ±15：

function calcDynamicLimit(actual, windowSize, offset) { const lower = []; const upper = []; for (let i = 0; i < actual.length; i++) { const start = Math.max(0, i - windowSize + 1); const slice = actual.slice(start, i + 1); const avg = slice.reduce((a, b) => a + b, 0) / slice.length; lower.push(Math.round((avg - offset) * 10) / 10); upper.push(Math.round((avg + offset) * 10) / 10); } return { lower, upper }; }

上下限一旦动态化，方案 B 的优势就完全体现出来了：只需要保证lower、upper、diff三个数组长度一致并及时更新，区域就会自动跟着阈值曲线走，完全不需要改绘图代码。

4. 动态更新、多指标扩展与响应式适配

静态 Demo 能跑通只是第一步，真正落到监控大屏和业务系统里，还要面对数据轮询、多指标并存、屏幕适配这些现实问题。

4.1 定时刷新数据的正确姿势

监控看板最常见的是每 3 秒或每 5 秒拉一次新数据。用setOption更新时，最好通过series.name来匹配，而不是用系列下标，这样即使以后在 series 中间插入新系列，代码也不会串位：

setInterval(() => { const newData = genData(30); chart.setOption({ xAxis: { data: newData.times }, series: [ { name: '下限', data: newData.lower }, { name: '区间', data: newData.diff }, { name: '上限', data: newData.upper }, { name: '实际值', data: newData.actual } ] }); }, 3000);

这里有一个非常容易踩的坑：只更新 actual、lower、upper，把 diff 给漏了。我之前就在这个坑里栽过一次。因为区域填充依赖的是diff系列，如果 lower 和 upper 变了而 diff 没变，填充区域就是错的，而且特别难排查——线都对，区域就是诡异。

所以动态更新时，所有辅助数组必须在同一轮计算里同步生成、同步提交。

如果数据点是持续增长的流式数据，可以用appendData追加。但appendData对多系列场景比较麻烦，需要每个系列各自维护数据缓冲，我的经验是：监控看板的数据量通常不会大到纯追加不可行，直接用setOption整体替换 30~100 个点的数组，性能完全没问题。真正的大数据量优化在下一章讲。

4.2 封装一个通用函数，避免重复造轮子

一个监控平台上通常有十几个指标：温度、压力、流量、振动……不可能每个指标复制一份 option。我通常会写一个工厂函数：

function createLimitChart(dom, { actual, lower, upper, unit = '', lineColor = '#5470c6', fillColor = 'rgba(255, 152, 0, 0.15)' }) { const chart = echarts.init(dom); const diff = actual.map((v, i) => upper[i] - lower[i]); chart.setOption({ // grid, tooltip, xAxis, yAxis 基础配置... series: [ { name: '下限', type: 'line', stack: 'band', data: lower, lineStyle: { type: 'dashed', color: '#ff9800' } }, { name: '区间', type: 'line', stack: 'band', data: diff, areaStyle: { color: fillColor }, tooltip: { show: false } }, { name: '上限', type: 'line', data: upper, lineStyle: { type: 'dashed', color: '#ff9800' } }, { name: '实际值', type: 'line', data: actual, lineStyle: { color: lineColor } } ] }); return chart; }

这样每个指标只需要传入自己的数据和单位即可。多指标并存时，每个指标各占一个容器，各调一次工厂函数，既隔离了配置，又便于单独销毁chart.dispose()。

如果多个指标要放在同一个坐标系里但量纲差异巨大，就得给 yAxis 配置成数组，并在每个 series 里指定yAxisIndex。要注意的是：上下限填充系列和实际值系列必须挂在同一个yAxisIndex上，否则视觉上会出现“实际值在上限之上”这种假象，其实人家根本不是同一个坐标系。

4.3 响应式适配的两个关键点

做可视化大屏时，图表不能跟着窗口缩放，是最常见的返工理由。基础做法是：

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

但在大屏系统里，容器不是整个窗口，可能是中间某个可拖拽面板，这时window.resize不灵敏。更稳的做法是用ResizeObserver监听容器本身：

const observer = new ResizeObserver(() => chart.resize()); observer.observe(document.getElementById('chart'));

还有一个非常容易忽略的细节：容器必须有明确高度。echarts.init初始化时如果容器高度为 0，图表会直接渲染异常或空白。很多 flex 布局下height: auto的容器都容易踩这个坑。建议在样式里给图表容器设置固定高度，或者用min-height兜底。

5. 踩坑记录：堆叠顺序、断层数据、tooltip 干扰与性能优化

这部分是我最想写的。上下限区域展示的实现原理并不复杂，但实际用起来有一堆隐藏的雷，网上很多博客都没讲清楚。

5.1 坑一：点击图例隐藏“下限”，整个区域掉到地上

这是最容易踩的坑。legend.data里虽然只列了“实际值、上限、下限”，“区间”系列不在图例中，但只要“下限”系列可以被点击隐藏，堆叠的底部基准就没了，diff系列会一下子掉落到 y = 0 基准线，整个填充区域变成直角三角形一样的大色块，图表直接“翻车”。

我在代码里用了legend: { selectedMode: false }一劳永逸地禁止图例切换显隐。如果产品经理一定要允许用户隐藏系列，那就得监听legendselectchanged，在事件里强制把“下限”和“区间”重新设为选中。我个人建议监控类图表直接禁掉图例交互，因为隐藏任何阈值线都会让区域语义失真。

5.2 坑二：数据断层与 null 值导致区域断裂

实际业务里的数据不是完美的，调取接口偶尔返回null，或者某些时间点数据缺失。当lower或diff某个点是null时，堆叠面积会出现断层，色带中间突然少了一块。

connectNulls只能在一部分场景下缓解断线问题，对面积填充的效果不稳定。更可靠的做法是在数据接入层做清洗：缺失点做线性插值，或者往前填充上一个有效值。

function fillNull(arr) { let last = null; return arr.map(v => { if (v == null) { return last; } last = v; return v; }); }

清洗时机很重要。要先把 actual、lower、upper 三个数组都清洗对齐，再算diff。顺序错了，diff 里也会带 null，后面极难排查。

5.3 坑三：tooltip 里冒出“区间”和差值

默认情况下，tooltip会把所有系列都列出来，“区间”系列的值是 upper - lower 的差值，用户看到“区间：50”大概率会一头雾水。更关键的是，“上限”如果是独立系列，tooltip 默认显示还好；如果照着部分简化教程把 upper 放进 stack，tooltip 里显示的“上限”会变成差值，数字完全不对。

处理方案就是在diff系列的配置里显式加tooltip: { show: false }，同时在全局 formatter 里再过滤一次，双保险。这样 tooltip 里永远只有实际值、上、限、下限三个有效信息。

5.4 坑四：大量数据点时的卡顿优化

当数据点从几十个涨到几千个，默认配置的图表会明显卡顿。我的优化习惯是四个“关掉/开上”：

• symbol: 'none'：几千个点没必要每个都画圆圈。
• sampling: 'lttb'：LTTB 采样算法可以在保留视觉趋势的前提下大幅减少渲染点数。
• animation: false：实时滚动更新时，动画只会增加每帧计算量，视觉意义不大。
• 用dataZoom的 inside 类型做一个窗口，焦点始终保持在末端最新数据。

sampling是 ECharts 折线图里性价比最高的性能开关，建议数据量超过 500 点就打开。

5.5 坑五：y 轴范围把上下限区域“切”掉了

如果实际波动范围是 35~85，但某天异常值冲到 120，而 y 轴max还是写死的 100，整个上限区域和越界部分就会被裁掉，看起来好像“没有越界”。这等于监控功能失效。

解决思路有两个：

• 如果业务清楚数据通常不会超过某个量程，就把min/max设为量程范围，异常值超出量程时，说明设备本身已经进入告警态。
• 如果数据波动不确定，就设置scale: true，让 y 轴跟随数据自动伸缩。但要适度，自动伸缩会导致上下限区域在视觉上被放大或缩小，用户对“越界多少”的直观感受会失真。

监控场景我倾向于前者，量程固定，区域表现稳定；分析报表场景用后者，保证数据完整。

5.6 其他零碎问题汇总

最后再说一个实用技巧

上下限区域展示看起来是个小功能，但把它做稳定需要考虑数据、视觉、交互三层的事情。这里分享一个我后来一直沿用的做法：把“下限、区间、上限”这三个辅助系列写成一个独立的 data processor，而不是随手写在 setOption 里。这样后续任何指标接入，只要把原始数据交给 processor，拿到的就是 format 好的 lower、upper、diff 数组；绘图组件只负责渲染，数据逻辑完全独立。代码结构清楚之后，后面加动态阈值、加多指标、加告警联动，都会顺手很多。

如果你正在做监控看板或者数据报表，建议先照着完整 Demo 跑通静态效果，再逐步加上动态数据和响应式适配，最后再根据实际场景做视觉微调。这个组合方案我已经在多个项目里验证过，稳定性和可维护性都经得起考验。