三种Heikin Ashi蜡烛实现方案差异及可靠性求证

问题背景 #

测试基于Heikin Ashi（HA）蜡烛的交易策略时，尝试了三种HA蜡烛实现方式：两次使用request.security函数调用，一次手动数学计算，但三种方式输出结果均不一致，需要明确哪种实现最可靠，以及差异产生的原因。

三种实现代码 #

1. 多次调用security函数的实现 #

UseHAcandles    = input(true, title="Use Heikin Ashi Candles in Algo Calculations")
hkClose = UseHAcandles ? request.security(ticker.heikinashi(syminfo.tickerid), timeframe.period, close) : close
hkOpen  = UseHAcandles ? request.security(ticker.heikinashi(syminfo.tickerid), timeframe.period, open) : open
hkHigh  = UseHAcandles ? request.security(ticker.heikinashi(syminfo.tickerid), timeframe.period, high) : high
hkLow   = UseHAcandles ? request.security(ticker.heikinashi(syminfo.tickerid), timeframe.period, low) : low

2. 单次调用security函数的实现 #

[hkOpen, hkHigh, hkLow, hkClose] = 
request.security(ticker.heikinashi(syminfo.tickerid), timeframe.period, [open, high, low, close])

3. 手动数学计算的实现 #

hkClose         = (open + high + low + close) / 4
hkOpen          = (open[1] + close[1]) / 2     
hkHigh          = math.max(high, math.max(hkOpen, hkClose))
hkLow           = math.min(low,  math.min(hkOpen, hkClose))

可靠性结论 #

最可靠的实现方式是单次调用security函数的版本（实现2）。

差异原因分析 #

1. 实现1与实现2的差异 #

实现1通过四次独立的request.security调用获取HA蜡烛的四个价格，虽然目标数据源和周期一致，但在实时行情场景或数据加载阶段，可能因调用时机的细微偏差（比如恰好遇到K线切换节点），导致某次调用获取到新K线数据，而其他调用仍停留在旧K线，最终拿到的四个价格不属于同一根HA蜡烛，出现数据不一致。

实现2则是一次性请求同一根HA蜡烛的四个价格，平台会保证返回的open/high/low/close属于同一根K线，从根本上避免了异步调用带来的同步问题。

2. 手动计算与security实现的差异 #

手动计算的公式看似符合HA蜡烛的标准定义，但存在几个关键问题：

• 初始值错误：HA蜡烛的开盘价是递归计算的，第一根HA蜡烛的开盘价应等于原始K线的开盘价，但手动代码中hkOpen = (open[1] + close[1])/2，第一根K线没有前序数据（open[1]和close[1]无效），平台会自动填充默认值或前推数据，导致初始HA蜡烛的开盘价错误，后续递归计算的所有数据都会偏离。
• 实时数据处理差异：平台内置的HA蜡烛在实时行情中，会根据最新成交价格动态更新未闭合K线的HA值；而手动计算依赖当前原始K线的close（实时场景下是最新价），但两者的实时更新逻辑可能存在差异，导致结果不同。
• 数据对齐与递归偏差：回测时，手动计算的递归逻辑依赖前一根HA蜡烛的结果，如果遇到数据缺口、周期切换等场景，容易出现数据对齐错误，而平台提供的HA数据源是预先计算好的完整序列，不存在这类问题。

内容的提问来源于stack exchange，提问作者xBruV