MQL5 EA异常处理与错误恢复完全指南

从错误码识别 → 分级处理 → 自动重试 → 状态恢复 —— 让你的EA在实盘中真正"打不死"

引言：你的EA会"悄悄死掉"吗？

90%的实盘EA，不是死在策略不行，而是死在异常处理缺失。

回想一下这些场景：

• EA连续跑了一个月都没事，某天凌晨2点网络闪断30秒，重连后EA就"罢工"了——指标句柄失效、订单状态错乱，却什么都不做
• 一次非农行情，滑点远超预期，OrderSend连续失败3次，EA直接躺平，后面的交易信号全部错过
• 换了一个VPS服务器，时区不一样，EA的时间判断全部错位，该平仓的时候不平，该开仓的时候乱开
• 更可怕的是——它什么都不报错。你早上起来一看，账户浮亏20%，EA还在图表上"正常运行"的假象里默默等死

这些不是策略问题，是工程健壮性问题。一个EA在回测里表现再好，如果没有完善的异常处理和错误恢复机制，放到实盘就是一颗定时炸弹。

本文系统梳理MQL5 EA开发中常见的6大类异常、对应的错误码识别方法、分级处理策略，以及一个完整的自动错误恢复框架——让你的EA从"一碰就碎"变成"打不死的小强"。

一、MQL5异常的6大类型与错误码体系

1.1 交易操作异常

交易操作异常是最常见的一类——开仓失败、平仓失败、改单失败。MQL5通过 GetLastError() 返回错误码，通过 OrderSend() / PositionClose() 的返回值判断操作是否成功。

最常见的交易操作错误码：

1.2 指标句柄异常

指标句柄失效是一个极其隐蔽的问题——网络重连、终端重启、品种切换，都可能导致 iMA() / iRSI() 等函数返回的句柄变成 INVALID_HANDLE。如果不检查，CopyBuffer() 会静默失败，返回0值数组，EA基于错误数据做出错误决策。

1.3 数据拷贝异常

CopyBuffer() 和 CopyRates() 是EA的"数据生命线"。当数据不足、网络断开或历史数据未加载时，这些函数会返回 -1 或返回数量不足预期。很多EA开发者直接假设数据一定能拿到，不做返回值检查，导致后续计算全部基于垃圾数据。

1.4 内存与数组异常

MQL5的数组越界、空指针访问、动态数组分配失败等问题，会直接导致EA崩溃（OnTick 抛出异常后终止运行）。尤其是处理历史数据时，数组大小与预期不一致是非常常见的崩溃原因。

1.5 网络与连接异常

VPS断网、经纪商服务器维护、MT5终端掉线——这些情况在实盘中几乎必然遇到。EA需要能检测连接状态，在断线期间停止交易操作，在重连后自动恢复状态（重新获取指标句柄、重新同步持仓状态）。

1.6 文件与配置异常

很多EA依赖外部文件保存参数或状态——INI配置文件、CSV日志文件、JSON状态文件。文件不存在、权限不足、磁盘满、格式损坏，都会导致EA初始化失败或运行中断。

二、错误分级处理策略

不是所有错误都需要同样的处理方式。把错误按严重程度分级，才能做到"小错不影响运行，大错及时止损"。

2.1 四级错误分级体系

2.2 指数退避重试机制

对于L1瞬时错误，不能"立即重试"——那会让情况更糟（比如4016请求过频，你重试越快被限制越狠）。正确的做法是指数退避（Exponential Backoff）：第一次等1秒，第二次等2秒，第三次等4秒，逐步放大重试间隔。

代码结构示例：

// 交易操作的带重试封装
bool SafeOrderSend(CTrade &trade, ulong &ticket, int maxRetries=3)
{
   int baseDelay = 1000; // 基础延迟1秒
   for(int i = 0; i <= maxRetries; i++)
   {
      bool result = trade.Buy(0.1, _Symbol, 0, 0, 0, "test");
      if(result) 
      {
         ticket = trade.ResultOrder();
         return true;
      }
      
      int err = (int)trade.ResultRetcode();
      if(!IsRetryableError(err))
      {
         LogError("不可重试错误", err, trade.ResultRetcodeDescription());
         return false;
      }
      
      if(i < maxRetries)
      {
         int delay = baseDelay * (1 << i); // 1s, 2s, 4s
         LogWarning(string_format("第%d次重试，等待%d毫秒", i+1, delay));
         Sleep(delay);
      }
   }
   LogError("重试次数耗尽，交易失败");
   return false;
}

三、6类异常的实战处理方案

3.1 交易操作失败：SafeTrade封装类

最基础也是最重要的一步——永远不要直接调用 CTrade.Buy() / Sell()。而是封装一个"安全交易"类，在内部统一处理重试、错误码判断、日志记录。

一个完善的 SafeTrade 类应该包含：

• 自动重试（仅对可重试错误）
• 错误码自动解析与分级
• 交易结果详细日志（手数、价格、滑点、成交时间）
• 连续失败计数（超过阈值升级为L3/L4）
• 自动交易状态预检

3.2 指标句柄失效：句柄健康检查机制

在 OnTick() 的最开始，先做一次"指标句柄健康检查"——如果发现任何句柄无效，立即重新创建并跳过本次tick。

代码结构示例：

// 句柄数组和名称（便于日志定位）
int      g_handles[];
string   g_handleNames[];
int      g_handleCount;

// 检查所有指标句柄是否有效
bool CheckIndicatorsHealth()
{
   bool allValid = true;
   for(int i = 0; i < g_handleCount; i++)
   {
      if(g_handles[i] == INVALID_HANDLE)
      {
         LogError("指标句柄失效: " + g_handleNames[i]);
         allValid = false;
      }
   }
   if(!allValid)
   {
      LogWarning("开始重建所有指标句柄...");
      ReleaseAllIndicators();
      InitAllIndicators();
   }
   return allValid;
}

void OnTick()
{
   // 第一步：句柄健康检查
   if(!CheckIndicatorsHealth())
      return; // 跳过本次tick，等待下次
   
   // 第二步：数据拷贝检查
   // ... 正常业务逻辑
}

3.3 数据拷贝失败：防御性数据获取

CopyBuffer() 有两个常见坑：① 返回 -1 表示失败；② 返回数量少于预期（历史数据还在加载中）。两种情况EA都不能继续计算。

正确的获取方式：

// 安全获取指标缓冲区
bool SafeCopyBuffer(int handle, int bufferIndex, double &buffer[], int count)
{
   int copied = CopyBuffer(handle, bufferIndex, 0, count, buffer);
   
   if(copied <= 0)
   {
      int err = GetLastError();
      LogWarning(string_format("CopyBuffer失败: handle=%d, err=%d", handle, err));
      return false;
   }
   
   if(copied < count)
   {
      LogWarning(string_format("数据不足: 期望%d, 实际%d", count, copied));
      return false;
   }
   
   // 额外检查：数据是否全为0（可能句柄已坏但CopyBuffer仍返回）
   bool allZero = true;
   for(int i = 0; i < copied && allZero; i++)
   {
      if(buffer[i] != 0.0) allZero = false;
   }
   if(allZero && count > 10)
   {
      LogWarning("指标数据全为零，疑似句柄异常");
      return false;
   }
   
   return true;
}

3.4 数组越界与内存异常

MQL5的数组越界会直接导致EA终止，不会有"友好的"异常提示。最容易踩坑的场景：

• 访问 Close[100] 但K线只有50根——尤其是新加的品种或刚启动的图表
• ArrayResize() 后假设成功，但实际内存分配失败返回false
• 对象指针为null时调用方法——在MQL5里会直接崩

3.5 网络断连与重连恢复

网络断连是实盘中的常态。EA需要具备"连接感知"能力：

检测连接状态的三个关键指标：

• TerminalInfoInteger(TERMINAL_CONNECTED) — 终端是否连接到交易服务器
• AccountInfoInteger(ACCOUNT_TRADE_MODE) — 账户信息是否能正常获取
• SymbolInfoDouble(_Symbol, SYMBOL_BID) — 行情数据是否在更新（对比上次价格是否变化）

断连后的恢复流程：

1. 检测到断连 → 设置 g_isConnected = false，暂停所有交易操作
2. 每次tick检查连接状态，直到恢复
3. 连接恢复后 → 执行 RecoverFromReconnect() 状态同步：
   • 重新获取所有指标句柄
   • 重新同步持仓列表（对比内存中的持仓与实际持仓）
   • 重新同步挂单列表
   • 重建所有定时器和事件监听
4. 状态同步完成 → 恢复正常交易

3.6 文件与配置异常

文件操作的防御性检查清单：

• 文件打开前检查是否存在：FileIsExist()
• 文件打开后检查句柄：if(handle == INVALID_HANDLE)
• 读取操作检查返回值，不要假设一定读到了数据
• 写入操作检查返回值，磁盘满、权限不足都会导致写入失败
• 文件操作结束后必须关闭句柄，防止文件句柄泄漏

四、构建完整的EA错误恢复框架

4.1 状态机设计

一个健壮的EA不应该只有"运行"和"不运行"两种状态。用有限状态机（FSM）来管理EA的运行状态，是错误恢复框架的骨架。

EA的5种核心状态：

4.2 恢复超时与升级机制

错误恢复不能无限期等待。如果RECOVERING状态持续了N分钟仍无法恢复正常，应该"升级"为更高级别的错误处理——从局部重试升级到状态重建，再升级到紧急停机。

4.3 紧急停机保护

紧急停机（Emergency Shutdown）是EA的最后一道防线。触发条件包括：

• 自动交易被禁用（错误码4114）
• 连续交易失败次数超过阈值（如连续10次开仓失败）
• 错误恢复超时（如5分钟内无法恢复正常状态）
• 检测到账户异常（如余额骤降、持仓数量异常）
• 日亏损达到预设上限（如单日亏损超过账户的5%）

五、日志系统：异常排查的"黑匣子"

没有完善的日志，异常处理就是盲人摸象——你知道出了问题，但不知道为什么出的、什么时候出的、出了之后EA做了什么。

5.1 日志分级

和错误分级对应，日志也应该分级：

• DEBUG — 调试信息，开发阶段使用，正式版关闭
• INFO — 正常运行信息，如开仓、平仓、参数变更
• WARNING — 警告，非致命但需要关注，如重试成功、数据延迟
• ERROR — 错误，交易失败、句柄失效等影响正常运行的问题
• FATAL — 致命错误，紧急停机、账户异常等

5.2 结构化日志

不要只打"开仓失败"这样一句话。好的日志应该包含：时间、级别、模块、错误码、错误描述、上下文信息。

对比一下：

❌ 不好的日志：开仓失败

✅ 好的日志：[2026-08-20 14:32:15][ERROR][TradeModule] Buy失败: symbol=XAUUSD, lot=0.1, error=4107, desc=Invalid stops, 当前stopLevel=50点, 尝试设置SL=30点

六、实战避坑：5个容易忽略的异常场景

坑1：周末/节假日服务器重启

很多经纪商在周末会重启交易服务器，导致MT5终端短暂断开。如果EA没有重连恢复机制，周一开盘时EA已经"死"了。

坑2：DLL调用失败

如果你的EA调用了外部DLL（如ZeroMQ、MySQL等），DLL加载失败、函数不存在、版本不兼容都会导致EA崩溃。使用DLL前必须做加载校验。

坑3：时区与时差问题

换了VPS、换了经纪商，服务器时区可能不一样。EA中所有时间判断如果硬编码了时区偏移，换环境就会出问题。使用 TimeTradeServer() 获取服务器时间，而不是依赖本地系统时间。

坑4：魔法数字冲突

如果同一个账户上运行了多个EA，且魔法数字相同，它们会互相干扰对方的订单。EA应该在初始化时检查是否有"非本EA魔法数字"的持仓，如果有，发出警告（但不要动它们）。

坑5：内存泄漏

MQL5的new/delete需要手动管理。如果EA中使用了动态对象但没有正确释放，运行几周后内存会持续增长，最终导致终端崩溃。在 OnDeinit() 中确保所有new出来的对象都被delete。

总结：从"能跑"到"耐操"的工程化升级

EA开发的真正分水岭，不是策略有多复杂，而是工程健壮性。

一个策略普通但异常处理完善的EA，实盘中能稳定跑一年；一个策略惊艳但容错为零的EA，可能活不过一个非农夜。

回顾本文的核心内容：

从今天开始，打开你正在跑的EA，对照这6类异常一项一项检查：

• 交易操作有重试吗？有错误码判断吗？
• 指标句柄有健康检查吗？
• 数据拷贝有返回值校验吗？
• 断连后能自动恢复吗？
• 有紧急停机保护吗？
• 日志能帮你排查问题吗？

如果上面6个问题有3个以上答不上来，你的EA可能正带着"裸奔"——回测里看起来很好，实盘一遇到异常就趴下。花一天时间把异常处理补上，比花一周优化策略参数更能保护你的账户。