MQL4锁仓EA源码解析：订单配对、对冲距离与止盈巡检避坑

简介《锁仓顺势加码EA源码》是一份面向外汇自动交易学习者与MetaTrader平台EA开发者的源码文档围绕锁仓、顺势加码、手动订单止盈、自动平仓和对冲单管理等常见需求展开适合希望理解MT4自动交易逻辑、梳理订单处理流程并参考参数设计的中级读者。压缩包共1个doc文件约45KB内容以源码注释、函数说明和参数配置为主便于对照阅读。文档涉及USE_ATR、PercentATR、HedgingLevel、AutoTakeProfit等外部参数并拆解Hedge_Assistante、start、OrderSelect、OrderClose等关键函数同时结合ATR、iHigh与iLow说明波动率计算和价格高低点获取思路预览中还保留了版本修订注释及BUY/SELL手动订单止盈、改单、平仓的处理片段可帮助读者理解EA从信号判断到订单管理的组织方式。已有1381人学习适合用作外汇EA入门拆解与二次开发参考。1. 锁仓这件事代码里真正在解的是一个“配对”问题打开这份锁仓顺势加码 EA 源码第一眼容易看错重点。文件名叫“顺势加码”可start()里只有一行Hedge_Assistante()通篇找不到真正意义上的加仓模块代码最复杂的地方是“怎么把一张对冲单认回它对应的手动单”。OrderSend的第九个参数本该填魔术号这里填的却是一张手动单的票号——对冲单不靠品种、方向或价格认主而是把主人的订单号标记在自己身上。这个反直觉的选择决定了整套锁仓机制能否在一堆乱序订单里保持配对正确。搞懂它比抄一份能跑的源码有用得多。2. 订单配对没有对象就用整数当指针MQL4 没有对象也没有引用订单池是一张线性表访问方式是“游标 快照”——OrderSelect把全局游标移到某一单上之后所有OrderOpenPrice()、OrderLots()读的都是这一单的字段。任何一次新的OrderSelect都会改写游标。所有配对逻辑都必须建立在这个前提上否则代码看着没错跑起来全是别人的数据。2.1 MagicNumber 被当成外键用先看“找手单、查配对、补对冲”这一整段这是整个 EA 的核心循环// 扫描持仓挑出手动单本品种、Magic0、已经成交 for (i 0; i OrdersTotal(); i) { if (OrderSelect(i, SELECT_BY_POS, MODE_TRADES) false) break; if (Symbol() OrderSymbol() OrderMagicNumber() 0 OrderProfit() ! 0) { Hedge 0; Ticket OrderTicket(); // 先存下来后面任何 OrderSelect 都会改游标 Type OrderType(); double Lots OrderLots(); double OpenPrice OrderOpenPrice(); for (int j i; j OrdersTotal(); j) { if (OrderSelect(j, SELECT_BY_POS, MODE_TRADES) false) break; if (Ticket OrderMagicNumber()) Hedge; // 对冲单把主人的票号存在 Magic 里 } if (Hedge 0) { // 没找到配对补一张反向 STOP 挂单 if (Type OP_BUY) Tic OrderSend(Symbol(), OP_SELLSTOP, Lots, NormalizeDouble(OpenPrice - HedgingLevel, Digits), 0, 0, 0, Hedging DoubleToStr(Ticket, 0), Ticket, 0, Green); if (Type OP_SELL) Tic OrderSend(Symbol(), OP_BUYSTOP, Lots, NormalizeDouble(OpenPrice HedgingLevel, Digits), 0, 0, 0, Hedging DoubleToStr(Ticket, 0), Ticket, 0, Red); } } }这段代码里藏着三个必须看懂的细节。第一Ticket、Lots、OpenPrice必须先拷进局部变量因为内层循环的OrderSelect(j, ...)一出游标就跑到别人身上了之后再调OrderLots()拿到的是 j 号单的手数。第二配对判断是Ticket OrderMagicNumber()让对冲单的 Magic 反向指向手单票号形成一条单向索引手单本身 Magic 恒为 0天然成为“根节点”。第三OrderSend的第十个参数写的是Ticket也就是说这道关联不是靠注释字符串Hedging DoubleToStr(Ticket,0)建立的——那只是给人看的日志机器认的是 Magic。接着是反向清理手单平掉以后挂着的 STOP 单必须撤否则它会在某个价位突然成交变成一张没人管的裸单。// 反向检查对冲单的主人还在不在 for (i 0; i OrdersTotal(); i) { if (OrderSelect(i, SELECT_BY_POS, MODE_TRADES) false) break; if (Symbol() OrderSymbol() OrderMagicNumber() ! 0) { Hedge 0; Ticket OrderTicket(); int Magic OrderMagicNumber(); // 这一单记着的主人票号 for (j 0; j OrdersTotal(); j) { if (OrderSelect(j, SELECT_BY_POS, MODE_TRADES) false) break; if (Magic OrderTicket()) Hedge; // 拿 Magic 去比对手单的票号 } // 主人不在了且自己是挂单type 1就撤掉 if (Hedge 0 OrderType() 1) OrderDelete(Ticket); } }两个循环的方向正好相反正向循环拿“手单票号”去比别人 Magic反向循环拿“自己 Magic”去比别人票号构成了一个没有数据库的双向指针。OrderType() 1这个条件很关键它把已成交的对冲单排除在自动删除之外——v2.1 的注释写得很直白“对于已经成交的对冲单系统不能自动平仓或删除需要手动平仓”因为一旦对冲单成交两张单已经形成锁仓自动撤掉任何一边都等于强行认亏。2.2 OrderProfit() ! 0 这个判据的巧妙与裂缝判断一张单“是手动单”代码用的条件是Magic 0 OrderProfit() ! 0。后半句是在区分挂单和市价单挂单没有浮动盈亏OrderProfit()恒为 0市价单成交后随价格波动通常非 0。用浮盈来反推“已成交”是个很省事的写法省掉了OrderType() 2的判断。但这个判据在两种情况下会失效。一种是在开仓瞬间浮盈恰好为 0老式账户没有手续费、买卖价刚好吃掉点差此时这张已经成交的手单会被当作挂单跳过于是永远不生成对冲单其他订单更无法匹配上它。另一种是某些账户把库存费、手续费单独计入OrderProfit()的取值区间和预期不一致。常见的实现思路是真正稳的写法是OrderMagicNumber() 0 OrderType() 2直接按订单类型判定跟盈亏数值脱钩。源码里注释写着/*Actived!*/说明作者自己也知道这里是在“猜”状态而不是在“读”状态。还有一处更隐蔽内层配对循环写成for (int j i; ...)起点是 i 而不是 0。这意味着索引小于 i 的那些订单从来没被搜过。如果一张手单排在列表靠后、它的对冲单排在列表靠前这一轮就会因为Hedge 0而重复下单凭空多出一张 STOP。对冲单本身也会参与外层循环它OrderProfit()可能非 0只是被Magic 0挡住了所以大多数时候不出事但一旦 Magic 因为某些平台行为被重置成 0重复下单就立刻发生。这类问题在回测里几乎看不出来因为回测的订单排序和实盘不完全一致。3. 对冲距离一个变量装着两套单位配对解决的是“谁和谁是一对”对冲距离解决的是“这张 STOP 挂在哪个价位”。这里源码埋了一个会被大多数人忽略的语义分裂它是后面所有价格类问题的源头。3.1 同一个 HedgingLevel两种量纲extern bool USE_ATR true; extern int PercentATR 40; // 40% ATR extern double HedgingLevel 30; // start() 里每个 tick 都会重算一次 if (USE_ATR) HedgingLevel iATR(NULL, PERIOD_D1, 14, 0) * PercentATR / 100; else HedgingLevel HedgingLevel * Point;看清楚这两行的量纲差异。ATR 分支里iATR返回的是价格单位比如 EURUSD 日线 ATR 是 0.0120乘 40% 得 0.0048这个数直接拿去减开仓价是绝对价格距离。固定分支里HedgingLevel * Point把 30 变成 30 个报价点也是价格距离。两条路殊途同归最后都指向“价格”但中间变量的含义完全不同一个存的是 0.0048一个存的是 30。提示切换USE_ATR开关时HedgingLevel这个 extern 变量的语义会从“点数”变成“价格”同一个数值 30 在两种模式下差了四个数量级。这种同名不同义的设计是参数面最容易翻车的地方。再看iATR(NULL, PERIOD_D1, 14, 0)的最后一个参数 shift0。0 号 K 线是当前还没走完的日线这意味着 ATR 不是常量而是每个 tick 都在变——亚洲盘算出来可能 0.0030欧美盘开盘后半小时能翻一倍。源码的处理方式是把结果存回HedgingLevel这个全局变量然后在下单时读它。于是对冲距离实际上是一份“创建那一刻的 ATR 快照”一旦 STOP 单挂出去后续 ATR 再变也不会重算除非那张单被撤了重建。这个隐式快照有利有弊好处是同一张单的挂单价不会来回跳否则会无限改单坏处是行情突变后这个距离已经不能反映当下的波动止损保护的强度悄悄失效了。3.2 NormalizeDouble 和最小挂单距离挂单价写的是NormalizeDouble(OpenPrice - HedgingLevel, Digits)。Digits是报价小数位五位报价账户上就是 5NormalizeDouble把价格截到 0.00001 的精度。这行不能省OrderSend收到一个带 1e-8 尾巴的价格会直接返回 129invalid price。即便做了归一化OrderSend仍可能返回 130invalid stops。原因是对冲单属于 STOP 挂单平台对“挂单价离现价至少多远”有硬性限制这个值可以从MarketInfo(Symbol(), MODE_STOPLEVEL)读到。源码里完全没有做这项校验它默认ATR * 40%一定大于平台最小距离。多数品种、多数日子确实成立但遇到低波动品种、或者经纪商调高了最小距离下单就会持续静默失败——OrderSend返回负数代码只在Tic 0时才弹 Alert失败的分支什么也不打印策略就这样“看起来在跑实际没有对冲”。还有OrderSend里那个滑点参数填的是 0。对市价单来说 0 意味着不允许偏离报价容易频繁报 136off quotes对挂单来说这个参数本来就没意义只有前面几个价格参数有效。同一个函数签名要同时服务市价单和挂单参数语义会跟着订单类型漂移这是 MQL4 接口设计里一个绕不过去的坑——参数位固定含义由OrderType决定。4. 主动止盈一层巡检、一层修复AutoTakeProfit这一段是整份源码里工程味最重的部分它同时做了两件性质完全不同的事主动平仓和给服务器上的止盈价“打补丁”。理解这两层为什么都要有比看懂每一行判断更有价值。4.1 容差窗口是一个去抖区间for (i 0; i OrdersTotal(); i) { if (OrderSelect(i, SELECT_BY_POS, MODE_TRADES) false) continue; if (Symbol() OrderSymbol() OrderMagicNumber() 0 OrderProfit() ! 0) { if (Symbol() GBPUSD) TP 17; else TP 10; // 硬编码的魔法数字 if (OrderType() OP_BUY) { // 第一层价格已经走到止盈位直接市价平 if (Bid - OrderOpenPrice() TP * Point) { if (OrderClose(OrderTicket(), OrderLots(), Bid, 2, 0) true) { ... return(0); } } // 第二层止盈价不在 ±1 点容差内就改单 if (OrderTakeProfit() - OrderOpenPrice() (TP - 1) * Point || OrderTakeProfit() - OrderOpenPrice() (TP 1) * Point) { if (OrderModify(OrderTicket(), OrderOpenPrice(), OrderStopLoss(), OrderOpenPrice() TP * Point, 0, 0) true) { Sleep(10000); } } } // SELL 方向对称表达式顺序不同逻辑等价 } }第一层很好理解浮盈够了就立刻兑现不等服务器。第二层是“修复”这段代码本身不知道止盈价有没有被设过它只是每个 tick 拿当前 TP 和目标 TP 的差值去比只要落在(TP-1, TP1)这个 ±1 点的窗口之外就调一次OrderModify把目标价写回去。这是个典型的 reconcile 循环——不关心历史只看期望状态和实际状态的差。±1 点的死区是这段代码里最值得抄的一笔。如果没有这个容差价格每跳一次浮盈判断都在变OrderModify就可能被疯狂触发服务器端会限流甚至拒单日志里刷满改单记录。死区把“设置一次就够”的操作变成了幂等操作代价是止盈价可能和理论值差一点点。Sleep(10000)是同一个思路的粗暴版改单成功后硬等 10 秒防止下一次 tick 又进来改一遍。这个写法在单线程 EA 里副作用很大——EA 不处理行情 10 秒跳空时可能错过触发价或者醒来时订单已经不在列表里了。4.2 v2.2 为什么要把手单止盈清零// v2.2: 对冲单一旦存在就把手单的止盈清零 for (i 0; i OrdersTotal(); i) { if (OrderSelect(i, SELECT_BY_POS) false) continue; if (Symbol() OrderSymbol() OrderMagicNumber() ! 0 OrderType() 2) { Ticket OrderMagicNumber(); // 从对冲单反查回手单票号 if (OrderSelect(Ticket, SELECT_BY_TICKET) false) break; if (OrderTakeProfit() ! 0) if (OrderModify(Ticket, OrderOpenPrice(), 0, 0, 0, 0)) Alert(Ticket, 对冲单已生成, 系统将止盈改为零,需要手动开锁!); } }这段逻辑值得单独拎出来因为它是整份源码里唯一一处“主动放弃原有保护”的设计。假设手单 10 点止盈、对冲 STOP 挂在 30 点外。价格往有利方向走 10 点手单成交平仓此时对冲单还在 20 点之外挂着但它对应的“手单”已经不存在了。下一轮反向清理循环会把这张挂单识别为孤儿并删掉——本来也没事。真正的问题是时序如果手单平仓和挂单删除之间价格反转那张挂单可能先被触发变成一张完全没有人管的反向市价单锁仓就变成了反向开仓。v2.2 的解法是把矛盾提前掐掉只要对冲单存在手单就不许有自己的止盈止盈权收归系统统一管理。代价是手单失去了服务器端的保命单终端一断线就没人止盈了所以 Alert 里那句“需要手动开锁”不是客套是责任转移声明。这里OrderModify把止损也一并写成 0等于把手单彻底变成一个只受 EA 管、不受服务器管的仓位。这里有一处真实的逻辑打架如果AutoTakeProfit true4.1 那段巡检发现手单 TP 是 0差值0 - OpenPrice显然落在容差之外于是又把 10 点止盈写回去下一个 tickv2.2 再把它清零。两个功能在同一笔订单上来回改日志刷屏服务器限流。默认值AutoTakeProfit false恰好让这个冲突不暴露但这不是设计出来的互斥是默认参数蒙对了。常见的实现思路是加一个“已被系统接管”的标记比如用订单注释或者维护一张已清零票号的表让两段逻辑互斥而不是互殴。4.3 Point 在五位报价账户上的一笔血泪账TP 10然后TP * Point这里的Point是报价的最小变动单位五位报价上是 0.00001。10 × 0.00001 0.0001也就是 1 个 pip。而交易者口语里的“10 个点”通常指 10 个 pip等于 0.0010。差了整整 10 倍。这份源码的年代背景是四位报价为主流的时期那时Point就等于 pipTP 10名副其实。放到五位报价账户上跑止盈从 10 pip 缩水成 1 pip利润大概率还不够覆盖点差和手续费回测曲线会变成一条缓慢下滑的直线排查半天才发现问题出在Digits上。GBPUSD那个 17 点的特判也是同理17 pip 变成 1.7 pip失去了任何意义。注意凡是用Point直接乘以“点数”的地方都要先确认账户报价位数。稳妥写法是先算pip Point * (Digits 3 || Digits 5 ? 10 : 1)再做乘法这样同一份代码在四位和五位账户上语义一致。5. 避坑五条只有跑起来才会暴露的记录下面这些不是理论推演是这类锁仓 EA 在实盘和长周期回测里反复出现的典型故障。每一条都按“现象 → 原因 → 解决”写方便对照排查。5.1 订单状态与游标相关现象一手单明明成交了日志里却一直不生成对冲单止盈也不动。原因OrderProfit() ! 0这个“已成交”判据在浮盈恰为 0 时返回 false手单被当成挂单跳过。低点差账户、开仓瞬间、或者带手续费但浮盈刚好吃平的场景都会命中。 解决把条件换成OrderMagicNumber() 0 OrderType() 2用订单类型判断而不是浮盈数值。改完记得同步改主动止盈那段两处判据必须一致否则一边认为它是手单、另一边不认。现象二撤销孤儿对冲单时明明有两张该撤实际只撤掉一张。原因for (i 0; i OrdersTotal(); i)里执行OrderDelete之后订单立刻从列表移除OrdersTotal()减一而i照常前进紧邻的下一张就被跳过了。同样的坑也存在于OrderClose循环里。 解决倒序遍历或者“扫到没有再扫一遍”的收敛式写法// 倒序删除避免索引漂移删掉一个后后面元素的索引不会往前挤 for (int k OrdersTotal() - 1; k 0; k--) { if (OrderSelect(k, SELECT_BY_POS, MODE_TRADES) false) continue; if (Symbol() ! OrderSymbol()) continue; if (OrderMagicNumber() 0 || OrderType() 2) continue; // 只处理未成交的对冲挂单 if (!OrderSelect(OrderMagicNumber(), SELECT_BY_TICKET)) continue; // 主人已不在 if (OrderType() 1 OrderDelete(OrderTicket()) false) Print(Delete failed: , OrderTicket(), err, GetLastError()); }现象三开了AutoTakeProfit同一笔单的止盈价被反复修改日志里改单记录刷屏。原因与 v2.2 的清零逻辑互相覆盖一个写回 10 点一个清零形成振荡。表面看是“策略在调仓”实际是在空转。 解决两个功能做成互斥开关或者在清零时给订单打上标记注释字段或内存中的票号集合巡检时跳过已接管的单。这类“两个模块操作同一个字段”的冲突靠默认参数躲过去是最不可靠的做法。5.2 价格精度与接口约束相关现象四OrderSend返回 130对冲单一张都挂不上但 EA 没有任何报错。原因ATR 算出的距离小于平台最小挂单距离MODE_STOPLEVEL或者归一化后价格仍不对齐 tick size。代码只在Tic 0时弹提示失败分支完全静默。 解决下单前先读MarketInfo(Symbol(), MODE_STOPLEVEL)和MODE_TICKSIZE距离不足就抬高到最小合法值同时把所有OrderSend的失败分支补上Print和错误码别让失败无声无息。现象五五位报价账户上策略表现断崖式下滑止盈像是没设一样。原因Point从 0.0001 变成 0.00001所有写死“点数”的地方实际距离都缩小了 10 倍止盈被点差吃掉。 解决在init()里统一算一次 pip 系数并存成全局变量所有距离类参数都走这个系数换算而不是直接用Point。改完拿Digits打一行日志出来确认比在回测里猜快得多。6. 设计取舍锁住的位置不是风险是被推迟的决策把这份源码摊开看它的核心不是“对冲掉风险”——两张反向单同时存在时净头寸为零价格怎么走都不会再产生新的盈亏风险并没有消失只是被冻结在锁仓那一刻的浮亏上。真正被交换出去的是决策时间原本价格触到止损就必须认账现在变成“先挂一张反向单等着等我想清楚再开锁”。保证金占用翻倍换来的是一个可以无限延长的观察窗口。这个取舍在数学上不划算在心理上极其划算所以这类 EA 一直有人写、有人用。代码层面它有几处真正值得借鉴的工程手法。在没有对象、没有引用的语言里用整数键做双向关联把“谁是谁的对冲单”表达成两条单向索引这是一个很朴素的指针模拟用 ±1 点的死区把非幂等的改单操作变成幂等这是所有“期望状态 vs 实际状态”巡检逻辑的通用套路用Sleep粗暴限流虽然难看但它至少意识到改单是有成本的。反过来全表 O(n²) 扫描、每 tick 重算 ATR、把 17 和 10 这种业务参数硬编码在判断里、失败分支静默——这些都是原型代码的特征能跑但不能长期跑。我一般会这么验证这类源码到底靠不靠谱先在策略测试器里用“每个 tick”模式跑一段把每次OrdersTotal()的变化和票号打印出来肉眼对一遍手单和对冲单的数量关系是否始终是 1:1然后把OrderProfit() ! 0换成OrderType() 2做 A/B看结果差多少最后手动在持仓里开一张单、再平掉观察孤儿挂单有没有被及时撤掉。三步走完一套锁仓逻辑的骨架就摸清了剩下的加码、解锁、分批止盈都得自己在这个骨架上补。说个我自己踩过的坑早年间我拿一份类似的源码直接改参数上实盘回测漂亮得不像话实盘第一周就发现对冲单压根没挂出去——原因是那个品种的最小挂单距离被平台调过而代码里没有任何一处校验也没有一行失败日志。从那以后我再看任何 EA 源码第一件事不是看它的入场信号而是把所有OrderSend、OrderModify、OrderDelete的返回值挨个检查一遍确认每一条失败路径都有输出。希望这个习惯能帮你少走一段弯路也建议你拿到这份源码后先把订单配对和价格精度这两块吃透再谈策略本身。本文还有配套的精品资源点击获取