打开一份自带的顶部类指标，把源码从上往下读，最先要弄明白的不是条件写了几个，而是这个高点是怎么被确认的。通达信顶部信号拆解的核心分歧就在这里：判据依赖的是左侧已经走完的数据，还是把后一根的取值也拉了进来。前者在图上标出的点是事后才稳定的，后者会随着新数据出现而移动。把这一层分清，后面讲参数、讲误判才有落点。
一、顶部判据依赖哪一侧数据
高点确认需要一段回看窗口，窗口里的数据都已经走完，这类判据只用到左侧数据，是稳定的。麻烦出在另一类写法上：为了让拐点更「提前」，源码会用 REF 取后面若干根的值来参与比较。
| 写法 | 取数方向 | 图上表现 |
|---|---|---|
| 只用回看窗口 | 只取当前根与左侧根 | 标记位置固定，不随新数据移动 |
| 用负位移取右侧 | 取当前根右侧若干根 | 标记会移动，历史位置随时间改写 |
第二类写法在读取历史时，读到的是当根之后已经发生的数据，在实盘运行时读不到未来，所以两种状态下同一段源码给出的标记位置不同。这就是判断顶部类指标时最先要确认的一件事。
二、顶部判据的常用构造
常见的构造有三层，写法不同，依赖的数据侧也不同。
窗口内极值比较
用一段回看窗口取最高价，再判断当前根是否等于这个极值。这类写法只用左侧数据，是稳定的那一类。
窗口极值加确认根
在极值判据后面加一个确认条件，要求极值出现之后再过若干根才标记。加入确认根之后，标记位置会滞后若干根，代价是滞后，换来的是不移动。
拐点类函数
用专门的拐点识别函数取波峰位置。这类函数的实现方式决定了它是否依赖右侧数据，具体行为以本机函数说明为准，不同版本的实现存在差异。
{窗口内极值比较：只用左侧数据，标记不移动}
N := 20;
HH := HHV(H, N);
{当前根创出窗口内新高}
NEWHIGH: H > REF(HHV(H, N), 1);
{加入确认根：极值出现之后再等两根才标记}
CONFIRM: REF(NEWHIGH, 2);
把这三层的写法分开看，顶部类源码的结构就清楚了：前面取极值，中间定判据，后面加确认。三层里哪一层引入了右侧数据，整段判据的稳定与否就取决于它。判断一段顶部类源码可不可信，与其逐行读完，不如先定位它落在哪一层，再针对性核对。
把这三层的写法分开看，顶部类源码的结构就清楚了：前面取极值，中间定判据，后面加确认。读源码时按这三层定位，比从头逐行读效率高。
三、未来函数特征怎么识别
顶部信号拆解绕不开未来函数的识别，因为顶部天然是一个「事后才知道」的位置，源码作者为了让标记更贴合极值，容易引入右侧数据。
识别办法有两条。第一条是看 REF 的位移参数。REF(X, N) 里 N 为正取左侧，N 为负取右侧，出现负位移就说明用到了当前根之后的数据。第二条是看是否用了专门的未来函数，这类函数的名称与行为可以在本机函数说明里查到。
还有一个不写在源码里的识别办法：把这段指标挂到图上，记下它在某一段历史区间的标记位置，过一段时间再看同一个区间。标记位置变了，就是用到了右侧数据；位置没变，就是稳定的那一类。这个办法不需要读源码，但要等一段时间，且需要同一段数据保持可比。
四、三类误判场景
顶部判据的误判来自三个方向，各自的核对办法不同。
- 把右侧数据的标记当成实时信号。表现是复盘时看着标记位置很准，实盘时同一个位置还没出现。核对办法是做一次错位对照，见下一节。
- 把窗口下沿的点当成顶部。窗口取二十根时，二十根之内的最高点也会被标记，其中有一部分并不是一个真正的高点。这类误判会随着窗口变大而减少，代价是标记更滞后。
- 把走平的一段当成拐点。价格在一个窄幅区间里横向走动时，窗口内的极值会反复被刷新，标记密集出现。这类误判的根源是判据用的是「等于极值」而不是「明显高出」，两者在走平区间的表现差别明显。
三类误判都不产生报错，指标照常画标记，只有在具体区段上做对照才看得出来。
三类误判里，第二类最容易被忽略，因为窗口下沿的点在图上确实是一个局部高点，肉眼看不出问题。要把它挑出来，得换一个角度：把同一段判据用两个相差一倍的窗口长度各跑一次，两次都标记的位置是两种窗口都确认的，只在长窗口里出现的位置多半就是短窗口的下沿点。这一步不做，判据的疏密是否合理就没有参照。
五、用错位对照做验证
通达信顶部信号拆解读到这一层，下一步是验证：判据到底稳不稳定，用错位对照最直接。做法是把同一段判据的输出，与它向右平移若干根之后的结果放在一起比较。
{把原判据与向右平移的版本并排放在一起}
SIG := H > REF(HHV(H, 20), 1);
{原判据}
RAW: SIG;
{用 REF 向右平移两根的版本，两个信号都画出来对比}
SHIFT: REF(SIG, 2);
如果两个信号在位图上完全重合，说明原判据本身就是滞后两根的，没有用到右侧数据。如果两者不重合，说明原判据的位置早于真实可得的时点，其中就包含右侧数据。这个对照只用左侧数据，任何版本都能跑。
六、核对顺序与记录
把上面几节收成一份顺序，每次读一份新的顶部类源码都走一遍。
- 读源码里所有
REF的位移参数，找出有没有负值。 - 核对用到的函数名，在函数说明里查它是否依赖右侧数据。
- 按三层结构定位：取极值、定判据、加确认，看哪一层的写法与预期不同。
- 做一次错位对照，把原判据与平移两根的版本并排画出来。
- 换一次窗口长度重跑，确认标记的疏密变化符合预期，把两次的窗口值记在说明栏里。
这五步走完，通达信顶部信号拆解的两个核心问题就各自有了读数：判据依赖哪一侧数据、滞后又有多长。把这两项读出来，一段源码的脾气就摸清了。需要说明的是，函数名称与实现细节在不同版本和券商定制版之间存在差异，具体以本机函数说明为准；界面入口也请按自己的客户端核对。
本文只作技术研究口径，全部内容围绕信号构造与数据依赖展开，不涉及也不构成对任何标的的判断或取舍建议。通达信顶部信号拆解的最后一步，是把判据依赖的数据侧、窗口长度、滞后根数这三项写进公式说明栏。这三项写清楚了，后面无论谁读这段源码，都不需要重新走一遍上面的顺序。
