量化指标可视化实战：Java计算MACD/BOLL/WR，ECharts绘制图表

做量化系统开发这么多年，我发现一个特别容易被低估的环节：指标可视化。策略信号算出来了，回测收益也跑完了，但跟别人汇报或者自己复盘的时候，总不能丢一张 CSV 表格过去吧？更别提调试策略参数时，光看数字很难直观感受到"这个均线金叉是不是假信号""WR 超卖之后 BOLL 开口到底有没有收窄"。

正好前阵子有个项目需要在内部系统里把MACD、BOLL、WR三个常用指标画出来，并且要求跟后端 Java 接口直接对接，我用了不到一下午把整套链路跑通了，其中核心图表的搭建确实1 分钟就能完成。这篇文章就把这套实战方案完整拆开，从图表选型、指标计算、前端渲染到接口对接的坑，一次性说清楚。

不管你是做 Java 后端想给团队补一个简易行情看板，还是刚接触量化的新人想自己搭一套指标可视化工具，这篇文章都能直接参考。文章里给的代码不是伪代码，是我在项目里实际跑通的版本，你可以直接拷走改改就能用。

1. 为什么量化系统要自己画指标图：三款主流方案实测对比

先说一个现象：很多人一开始觉得"指标图而已，直接用 TradingView 或者某财富软件的图表组件不就行了"。真做起来你会发现，第三方现成组件跟你系统的数据格式、配色体系、交互方式往往对不上，而且外部服务的数据安全边界也是个问题。自己画虽然要写点代码，但从数据契约到展示效果都能完全掌控，这套东西做一次，后续所有策略都能复用。

做自研方案之前，我认真对比了三款主流方案：ECharts、TradingView Lightweight Charts、KLineChart。这里直接给结论：

我最终的选择是主图用 Lightweight Charts，副图用 ECharts。主图承载 K 线，交互体验专业；副图画 MACD、WR 这类指标，ECharts 的 grid 布局和 series 类型更灵活。后面章节会给出完整的对接代码。

如果你只想用一套库搞定，那直接用 ECharts 也没问题，我第三节会同时给出纯 ECharts 的搭法。原则就一个：先跑通链路，再追求体验。

1.1 先解决一个观念问题：指标图画什么、画在哪一层

量化系统里的指标可视化，通常涉及两个层面：策略信号标注和行情指标展示。这篇文章讲的是后者，也就是把 K 线和指标画在同一个时间轴上，方便肉眼对照。

MACD 是副图指标，展示 DIF、DEA 两条线和红绿柱；BOLL 是主图叠加指标，三条轨道线围绕 K 线；WR 本身是副图指标，反映超买超卖区间。所以你会看到我们的图表布局是：主图（K线+BOLL）、副图一（MACD）、副图二（WR）。这种"一主多副"的布局，是行情软件最通用的形态。

1.2 确认你的数据源：指标到底谁算？

这里有一个非常关键的设计决策：指标在前端算还是后端算？

我推荐后端算。原因有三：

1. 策略系统本身在 Java 侧，很多指标如 MACD 的 DEA 在写策略时已经算过，前端重复算没必要。
2. 表格数据或接口数据需要在多个端展示，后端统一计算能保证口径一致。
3. 前端计算指标会带来额外的调试成本和性能开销，尤其是在大量历史数据场景下。

所以下面先讲 Java 后端怎么算这三个指标、怎么定义数据契约，这是整个可视化的地基。

2. MACD BOLL WR 在 Java 端的计算与数据契约

很多刚开始做指标可视化的同学，卡住的第一关其实是后端数据格式。前端代码几分钟写完，但接口返回的数据对不上、指标少一根、时间戳单位错了，半天就没了。所以我们先把这三件事定死：指标怎么算、JSON 怎么设计、时间怎么对齐。

2.1 Java 实现 MACD：一个 EMA 数组搞定所有问题

MACD 的本质是两根均线的差值。快线是 12 周期 EMA，慢线是 26 周期 EMA，两者之差是 DIF；DIF 再做 9 周期 EMA 得到 DEA；柱状图的值是2 * (DIF - DEA)。这个"2 倍"是国内行情软件的约定（通达信、同花顺都这么显示），和国外一些平台不同，接国内数据时要注意。

代码里我推荐用一个函数维护 EMA 状态，避免为每条新 K 线从头计算：

public class MACDCalculator { private double ema12 = 0.0; private double ema26 = 0.0; private double dea = 0.0; private final double alpha12 = 2.0 / 13.0; private final double alpha26 = 2.0 / 27.0; private final double alphaDea = 2.0 / 10.0; private int count = 0; public double[] next(double price) { count++; if (count == 1) { ema12 = price; ema26 = price; dea = 0.0; } else { ema12 = (1 - alpha12) * ema12 + alpha12 * price; ema26 = (1 - alpha26) * ema26 + alpha26 * price; } double dif = ema12 - ema26; if (count > 1) { dea = (1 - alphaDea) * dea + alphaDea * dif; } double macdBar = 2 * (dif - dea); return new double[]{dif, dea, macdBar}; } }

注意 EMA 的初始值处理：第一根 K 线直接用收盘价作为 EMA 初值，前面少数几根 K 线的 MACD 会有预热期，数值不精确。前端展示时，可以跟后端约定把前几根"空窗期"数据返回null，让前端跳过绘制，比前端自己猜边界要干净。

2.2 BOLL 与 WR：一个统计学指标，一个动量指标

BOLL 布林通道，中轨是N 周期移动平均线，上轨和下轨在中轨基础上加减K 倍标准差。默认参数 N=20、K=2。代码里需要维护一个滑动窗口，实时计算标准差。

Java 实现时，注意标准差公式用的是总体标准差（分母除以 N），还是样本标准差（分母除以 N-1）。这直接影响上下轨宽度。国内行情软件用的是总体标准差，这里保持一致：

public class BollCalculator { private final int period = 20; private final double mult = 2.0; private final LinkedList<Double> window = new LinkedList<>(); public double[] next(double price) { window.addLast(price); if (window.size() > period) { window.removeFirst(); } if (window.size() < period) { return new double[]{Double.NaN, Double.NaN, Double.NaN}; } double ma = window.stream().mapToDouble(Double::doubleValue).average().orElse(0); double variance = window.stream() .mapToDouble(v -> Math.pow(v - ma, 2)) .average().orElse(0); double sd = Math.sqrt(variance); return new double[]{ma + mult * sd, ma, ma - mult * sd}; } }

WR（威廉指标）是动量类指标，衡量当前收盘价在最近 N 周期最高价与最低价之间的位置。默认 N=14。公式为：

WR = (HHV(N) - C) / (HHV(N) - LLV(N)) * 100

这里需要注意，WR 的数值范围是 0~100，超过 80 为超买区间，低于 20 为超卖区间。国内软件通常把 WR 的纵坐标倒置（数值大的在上方），后面前端配置里我会处理这个细节。

2.3 数据契约设计：一次全量还是增量增量

接口设计上，最简单有效的方式是：

{ "symbol": "600519", "period": "daily", "bars": [ { "time": "2024-11-01 09:30:00", "open": 1682.0, "high": 1710.0, "low": 1668.0, "close": 1700.5 } ], "indicators": { "macd": { "dif": [0.23, 0.45, null, 0.12], "dea": [0.11, 0.2, null, 0.15], "macdBar": [0.24, 0.5, null, -0.06] }, "boll": { "upper": [null, null, 27.5, 28.1], "mid": [null, null, 26.0, 26.4], "lower": [null, null, 24.5, 24.7] }, "wr": { "value": [88.5, 30.2, null, 15.6] } } }

关键点有四个：

1. time 字段统一用字符串，格式为yyyy-MM-dd HH:mm:ss，不要用毫秒时间戳。因为前端 ECharts 的 tooltip 格式化需要日期字符串，后端如果直接给毫秒，前端还得换算，接口文档也容易产生歧义。
2. 指标数组和 K 线数组一对一对齐，指标数组长度等于bars数组长度。对不上的位置用null占位，切不可缩短数组。
3. period 字段标记周期，daily / weekly / 1min / 5min 等。前端拿到 period 后决定坐标轴的显示粒度。
4. 一次性全量返回最近 200~500 根，实时更新走另外的增量接口（后面讲）。全量接口的重点是首次渲染不要分页，否则前端要写很多拼接逻辑。

3. 前端不写业务逻辑：1 分钟搭完三副图的完整代码

后端把数据契约定清楚之后，前端的工作量就很小了。这一节我把纯 ECharts 方案完整写出来——它是最容易起步的，一个 HTML 文件加一段 JS 就能跑，没有任何构建工具依赖。

3.1 初始化图表与三 grid 布局

ECharts 多副图布局的精髓在于grid 数组。主图占 55% 高度，MACD 副图占 20%，WR 副图占 15%，底部留 10% 给 dataZoom。我封装了一个createIndicatorChart函数，接收上面契约里的 JSON 数据：

const chart = echarts.init(document.getElementById('chart')); function createOption(data) { const bars = data.bars; const macd = data.indicators.macd; const boll = data.indicators.boll; const wr = data.indicators.wr; const times = bars.map(b => b.time); // K线数据 const kData = bars.map(b => [b.open, b.close, b.low, b.high]); // BOLL三条线，主图叠加 const bollUpper = boll.upper.map((v, i) => [times[i], v]); const bollMid = boll.mid.map((v, i) => [times[i], v]); const bollLower = boll.lower.map((v, i) => [times[i], v]); // MACD：柱状图 + DIF + DEA const macdBar = macd.macdBar.map((v, i) => [times[i], v]); const difLine = macd.dif.map((v, i) => [times[i], v]); const deaLine = macd.dea.map((v, i) => [times[i], v]); // WR const wrLine = wr.value.map((v, i) => [times[i], v]); const option = { animation: false, legend: { top: 0, data: ['K线', 'BOLL上轨', 'BOLL中轨', 'BOLL下轨', 'DIF', 'DEA', 'MACD', 'WR'] }, grid: [ { left: 50, right: 20, top: 40, height: '42%' }, // 主图 { left: 50, right: 20, top: '52%', height: '16%' }, // MACD { left: 50, right: 20, top: '72%', height: '13%' } // WR ], xAxis: [ { type: 'category', gridIndex: 0, data: times, boundaryGap: true }, { type: 'category', gridIndex: 1, data: times, axisLabel: { show: false } }, { type: 'category', gridIndex: 2, data: times, axisLabel: { show: false } } ], yAxis: [ { gridIndex: 0, scale: true }, { gridIndex: 1, scale: true }, { gridIndex: 2, min: 0, max: 100, inverse: true } // WR常用倒置 ], dataZoom: [ { type: 'inside', xAxisIndex: [0, 1, 2], start: 50, end: 100 }, { type: 'slider', xAxisIndex: [0, 1, 2], bottom: 5, height: 20 } ], series: [ // 主图：K线 + BOLL { name: 'K线', type: 'candlestick', data: kData, itemStyle: { color: '#ef232a', color0: '#14b143', borderColor: '#ef232a', borderColor0: '#14b143' } }, { name: 'BOLL上轨', type: 'line', data: bollUpper, xAxisIndex: 0, yAxisIndex: 0, symbol: 'none', lineStyle: { width: 1 } }, { name: 'BOLL中轨', type: 'line', data: bollMid, xAxisIndex: 0, yAxisIndex: 0, symbol: 'none', lineStyle: { width: 1 } }, { name: 'BOLL下轨', type: 'line', data: bollLower, xAxisIndex: 0, yAxisIndex: 0, symbol: 'none', lineStyle: { width: 1 } }, // MACD副图 { name: 'MACD', type: 'bar', data: macdBar, xAxisIndex: 1, yAxisIndex: 1, itemStyle: { color: function(params) { return params.data[1] >= 0 ? '#ef232a' : '#14b143'; } } }, { name: 'DIF', type: 'line', data: difLine, xAxisIndex: 1, yAxisIndex: 1, symbol: 'none', lineStyle: { width: 1 } }, { name: 'DEA', type: 'line', data: deaLine, xAxisIndex: 1, yAxisIndex: 1, symbol: 'none', lineStyle: { width: 1 } }, // WR副图 { name: 'WR', type: 'line', data: wrLine, xAxisIndex: 2, yAxisIndex: 2, symbol: 'none', lineStyle: { width: 1 } } ], tooltip: { trigger: 'axis', axisPointer: { type: 'cross' } } }; return option; } chart.setOption(createOption(data));

这段代码的核心思想是：把所有数据提前映射成[时间, 值]二元组，ECharts 内部会自动按时间对齐。三种指标的配色我沿用了国内行情软件的习惯——红涨绿跌，红柱为正、绿柱为负。

3.2 为什么这样一次性 setOption 而不是分多次

很多教程会教你"先渲染 K 线，再 append 指标线"。实测下来这完全没有必要，ECharts 的 series 支持一次全量声明，数据对齐在[x, y]二元组层面已经完成。一次性 setOption 还有一个好处：缩放、拖拽时三条副图联动完全由 dataZoom 的 xAxisIndex 决定，只要索引一致，联动是自动的，不用写任何事件同步代码。

如果你还需要把主图换成 Lightweight Charts，也很简单：主图单独初始化成lightweight-charts实例，副图继续用 ECharts，两个组件共享同一份后端数据。时间轴联动的做法是监听visibleLogicalRange事件，反向去调 ECharts 的 dataZoom，这块代码量不大，但需要一点事件同步的经验。

4. 对接真实接口绕不开的四个坑：对齐、增量、复权与性能

代码跑通只是第一步，真正接入生产环境，我从实际项目里总结出了四个高频坑。每一个都让我在调试上花了不少时间，提前写出来帮你避开。

4.1 坑一：指标数组的 null 处理不当，线会"断头"

前面提到，MACD 前几根 K 线没有 DEA，BOLL 前 19 根没有上下轨。如果你在后端把空值设为0而不是null，前端会画出从零点飙到真实值之间的竖线，图表瞬间像被刀砍了一刀。

解决办法就在后端：空值必须序列化为null，不能省略、不能填 0。前端 ECharts 对null数据默认有connectNulls属性控制是否越过空值连线，推荐设为false（默认即 false），让缺失区间留白，而不是猜测走势。这个约定要写进接口文档，很多 Java 后端会习惯性把空值变成 0.0，踩过一次就印象深刻了。

4.2 坑二：增量更新时 setOption 的合并陷阱

实时行情场景下，你不可能每次都把全量数据推给前端。常规做法是后端维护一个增量接口：

GET /api/kline/incremental?symbol=600519&period=daily&after=2024-11-01 14:00:00

返回新增的 bar 和指标数组。前端拿到增量数据后，需要把旧的bars和indicators数组concat一次，再整体 setOption。

这里有个我踩过的大坑：ECharts 的 setOption 默认是合并模式，如果你调用chart.setOption(newOption)时没有把旧的 candle 数据覆盖，图上会出现新旧数据重叠的杂乱画面。正确做法是：

chart.setOption({ series: [{ data: newKData }, { data: newBollUpper }] }, { replaceMerge: ['series'] });

或者更简单粗暴，每次增量更新直接把option.series全部替换，不留任何系列残留。增量接口的after参数要用 bar 的时间而不是当前时间，避免数据丢失。

4.3 坑三：复权口径不一致，指标算出来是歪的

做量化的人对复权都不陌生。前端展示历史 K 线时，必须明确前端展示的数据是前复权还是不复权，并且指标计算用的数据要和 K 线同源同口径。

我遇到的实际案例是：后端有两个接口，一个返回不复权行情，一个返回前复权行情，指标计算却统一用了不复权数据。前端拿到前复权 K 线后，把 BOLL 指标叠加上去，发现轨道完全偏离。排查半天，根源是前复权价格会随着新除权事件不断变化，历史数据每次复权都会变。如果指标是基于不复权价格算的，画在前复权 K 线上自然对不上。

正确做法是：在接口契约层就明确adjust字段（none / qfq / hfq），前后端都用同一个值。回测和实盘盯盘通常用前复权，但前端展示风险指标（如 BOLL 的绝对数值）时，不复权更直观。

4.4 坑四：大数据量渲染和滚动性能

当你在 dataZoom 里把范围拉满，一次性渲染 500 根 K 线加三条 BOLL 线、两条 MACD 线、一条 WR 线，ECharts 默认配置下会有明显卡顿。我实测 800 根 K 线时，帧率已经掉到可以感知的程度。

性能优化的三板斧：

chart.setOption({ animation: false, // 关闭动画，数据更新时不做过渡 progressive: 2000, // 设置 progressive 渲染阈值 series: [{ type: 'candlestick', large: true, // 开启K线大数据优化 largeThreshold: 300, // 超过 300 根启用 }] });

另外，animation: false对蜡烛图特别重要。实时刷新场景下，动画会造成 K 线闪烁和坐标轴跳动，关了之后反而干净。

5. 复盘：这套方案的扩展点与适用边界

项目上线之后，我陆续给这套图表加了不少扩展，过程比想象中顺。这里把我认为最值得做的几个方向列出来，你可以按需取舍。

5.1 买卖点标注：直接把策略信号画在图上

指标图最大的价值不只是"看"，是配合策略信号复盘。我在后端计算策略时，把每次金叉死叉、突破买入、止损卖出信号都记录下来，接口返回一个signals数组：

"signals": [ {"time": "2024-11-05", "type": "buy", "price": 26.4, "remark": "MACD金叉"}, {"time": "2024-11-18", "type": "sell", "price": 29.1, "remark": "BOLL触上轨"} ]

前端用 ECharts 的markPoint在第 0 个 grid（主图）上渲染：

series: [{ name: 'K线', type: 'candlestick', data: kData, markPoint: { data: signals.map(s => ({ coord: [s.time, s.price], value: s.type === 'buy' ? 'B' : 'S', itemStyle: { color: s.type === 'buy' ? '#ef232a' : '#14b143' } })) } }]

实测下来，配合 markLine 画出买入价和止损价，比任何文字汇报都直观。

5.2 周期切换与多合约对比

dataZoom 里把start和end通过 URL 参数透传，就能实现"从日线切到周线保留缩放位置"等交互细节。

另外，如果你想在同一张图上对比两个合约的 WR 强弱，只需新增一个 grid 和一个 series。数据契约层面不用大改，前端多加一个 grid 索引即可。这套方案的灵活性恰恰来自最初接口设计时就把"数据"和"展示"解耦了。

5.3 适用边界：什么场景不要用 ECharts 方案

说句公道话，如果你要做一个面向普通用户的高频交互看盘工具（要求秒级刷新、专业级十字光标、逐根 K 线左右键复盘体验），ECharts 不是最优解，Lightweight Charts 或 Canvas 自绘会更好。我的这套方案最适合的是内部量化研究平台、策略信号展示、回测结果复盘这类场景——数据量可控、交互要求中等、开发效率优先。

它最大的优势是：后端数据契约定义得当的情况下，前端真的可以做到 1 分钟搭完。我在团队里做演示的时候，从拿到接口文档到图表显示，只花了不到两分钟。这两分钟的时间主要花在确认字段名上，而不是写代码。

最后分享一个我在项目里反复体会到的经验：指标可视化这件事，前端永远是最轻松的一环，真正的工程量在数据对齐和后端计算口径上。如果你正在搭这套东西，我建议你先把接口返回的 JSON 打印出来，仔细检查一遍 null 占位、时间格式和指标长度，再开始写前端代码。否则前端改来改去，大概率都是后端数据的锅。

后续如果大家感兴趣，我可以再写一篇把增量推送升级为 WebSocket 实时推送的实战，以及 K 线主图换成 Lightweight Charts 后两套图表库如何做时间轴联动。这套方案目前在我这边已经稳定跑了几个月，希望你的项目也能顺利。