EA错误处理与容错机制实战：让你的EA不再"跑着跑着就出问题"

你的EA回测表现堪称完美——年化30%，最大回撤不到10%，夏普比率超过2。挂上VPS开始实盘，结果呢？下单失败没重试，网络断了EA一脸懵，跑了几天MT5越来越卡最后直接崩溃，有一笔订单止损没设上EA也不知道管。这些都不是策略问题，而是容错机制缺失。

风险提示：本文内容仅为技术工具分享与原理探讨，不构成任何投资建议。本网站仅提供软件开发技术服务，不涉及任何交易平台运营或经纪业务。所有交易行为均由用户自行决策并承担相应风险。

回测环境是"理想世界"——网络不断、服务器不重启、订单秒成交。实盘环境是"残酷世界"——网络波动、服务器维护、滑点、拒绝、超时。一个真相：EA的策略逻辑只占稳定性的30%，剩下70%靠的是错误处理和容错机制。

重点：本文8个容错模块覆盖5大维度：交易失败重试、网络断连恢复、指标句柄泄漏防护、异常订单自动处理、日志分级与状态持久化。每个模块都有完整MQL5代码，直接复制就能集成到你的EA中。

模块1：交易请求重试机制

OrderSend经常返回"可重试"错误——价格过期、重报价、服务器忙碌。不重试就直接放弃，等于白白送掉交易机会。我们需要一个带重试逻辑的交易函数。

知识点：MQL5交易返回码分为"可重试"和"不可重试"两类。可重试的包括：10004（重报价）、10014（无效价格）、10017（服务器忙碌）、10018（价格过期）——这些通常是临时性问题，重试后大概率成功。不可重试的包括：10006（被拒绝）、10015（无效手数）、10019（无效止损）、10022（交易禁止）——这些是逻辑性错误，重试也没用。

// 带重试机制的交易函数
bool SendOrderWithRetry(ENUM_ORDER_TYPE type, double lots, 
                          double sl, double tp, 
                          int maxRetries = 3, int retryDelayMs = 500)
{
    MqlTradeRequest request = {};
    MqlTradeResult  result  = {};
    
    request.symbol   = _Symbol;
    request.volume   = lots;
    request.sl       = sl;
    request.tp       = tp;
    request.deviation = 10;
    request.type     = type;
    request.magic    = MAGIC_NUMBER;
    
    for(int attempt = 0; attempt < maxRetries; attempt++)
    {
        // 每次重试前刷新价格
        request.price = (type == ORDER_TYPE_BUY) 
            ? SymbolInfoDouble(_Symbol, SYMBOL_ASK) 
            : SymbolInfoDouble(_Symbol, SYMBOL_BID);
        
        if(OrderSend(request, result))
        {
            if(result.retcode == TRADE_RETCODE_DONE)
                return true;
        }
        
        // 判断是否可重试
        if(result.retcode == TRADE_RETCODE_REQUOTE    ||
           result.retcode == TRADE_RETCODE_PRICE_CHANGED ||
           result.retcode == TRADE_RETCODE_PRICE_OFF     ||
           result.retcode == TRADE_RETCODE_BUSY)
        {
            Print("重试第", attempt+1, "次，错误码：", result.retcode);
            Sleep(retryDelayMs);
            continue;
        }
        else
        {
            Print("交易失败，不可重试错误：", result.retcode);
            return false;
        }
    }
    Print("重试", maxRetries, "次后仍失败");
    return false;
}

交易请求重试机制流程示意

操作参考：重试参数参考值：maxRetries=3次，retryDelayMs=500毫秒。对于波动大的品种（如黄金、加密货币），可考虑增加到5次，延迟递增（500→1000→2000ms）。我们的定制EA默认集成了智能重试机制，支持可重试错误的自动重试和日志记录。

模块2：网络断连检测与自动恢复

VPS断网后EA完全不知道，继续按旧数据做决策；恢复后状态不一致，持仓管理混乱。我们需要一个网络健康监测机制。

datetime g_lastTickTime = 0;
int g_maxTickGapSeconds = 120;  // 超2分钟没收到tick视为断连

bool CheckConnection()
{
    datetime now = TimeCurrent();
    if(g_lastTickTime == 0) { g_lastTickTime = now; return true; }
    
    int gap = (int)(now - g_lastTickTime);
    if(gap > g_maxTickGapSeconds)
    {
        Print("⚠️ 检测到网络中断！中断时长：", gap, "秒");
        RecoverAfterDisconnect();  // 执行恢复操作
        g_lastTickTime = now;
        return false;
    }
    g_lastTickTime = now;
    return true;
}

void RecoverAfterDisconnect()
{
    // 1. 重建所有指标句柄
    RecreateIndicatorHandles();
    // 2. 检查是否有挂单未成交
    CheckPendingOrders();
    // 3. 同步持仓状态
    SyncPositionState();
    Print("✅ 恢复完成，指标句柄已重建，持仓状态已同步");
}

风险：断连恢复时最常见的错误是"不检查直接继续交易"。断连期间可能有订单已经成交但EA不知道，导致重复开仓或持仓计算错误。恢复后必须先同步持仓状态、检查未完成订单，再恢复交易逻辑。

操作参考：在OnTick开头第一行调用CheckConnection()。如果返回false（刚断连恢复），本次tick跳过交易逻辑，只执行恢复操作。下一个tick开始正常交易。g_maxTickGapSeconds建议设为品种正常tick间隔的3-5倍，如EURUSD M5周期设为120秒，黄金M1周期设为60秒。

模块3：指标句柄泄漏防护

EA跑了几天后MT5越来越卡，最后直接崩溃——90%的原因是指标句柄没有释放。每次创建句柄（iMA、iRSI、iCustom等），如果不在OnDeinit中释放，句柄会持续累积，最终拖垮MT5。

知识点：指标句柄（Indicator Handle）本质是MT5内部的一个资源对象。每调用一次iMA()、iRSI()等函数，MT5就在内部分配一块资源。如果不调用IndicatorRelease()释放，这些资源会一直占用。一个句柄占用的内存不大，但EA运行几天可能创建成千上万个句柄，累积效应会导致MT5性能严重下降甚至崩溃。

// 句柄管理器——统一管理所有指标句柄
int g_handles[];
int g_handleCount = 0;

// 安全创建句柄（先释放旧的，再创建新的）
int SafeCreateHandle(int handle, string name)
{
    if(handle != INVALID_HANDLE)
        IndicatorRelease(handle);  // 先释放旧的
    
    // handle = 实际的创建代码...（此处省略）
    
    if(handle == INVALID_HANDLE)
        Print("❌ 句柄创建失败：", name);
    else
    {
        ArrayResize(g_handles, g_handleCount + 1);
        g_handles[g_handleCount] = handle;
        g_handleCount++;
    }
    return handle;
}

// 批量释放所有句柄
void SafeReleaseAllHandles()
{
    for(int i = 0; i < g_handleCount; i++)
    {
        if(g_handles[i] != INVALID_HANDLE)
            IndicatorRelease(g_handles[i]);
    }
    g_handleCount = 0;
    Print("✅ 所有指标句柄已释放");
}

重点：句柄管理器模式的核心思想是：每个新句柄创建时都注册到数组中，OnDeinit中统一释放。这样不会漏掉任何一个。如果EA需要动态创建/销毁指标（比如切换策略时），SafeCreateHandle会先释放旧句柄再创建新的，避免重复创建不释放。

模块4：OnTradeTransaction异步事件处理

用OnTick轮询检查订单状态，延迟高、效率低，经常漏掉交易事件。MQL5提供了OnTradeTransaction回调函数，可以实时监听所有交易事件。

进阶原理：OnTradeTransaction是MQL5的事件驱动交易监听机制，在交易线程中被调用（不是交易线程）。每当发生交易事件（订单创建/删除/成交、持仓变化、历史订单变更等），都会触发此回调。相比在OnTick中轮询PositionTotal()，它的优势是实时性强、不会遗漏事件、不需要额外的变量记录上次状态。

void OnTradeTransaction(const MqlTradeTransaction &trans,
                       const MqlTradeRequest &request,
                       const MqlTradeResult &result)
{
    // 只处理新成交事件
    if(trans.type == TRADE_TRANSACTION_DEAL_ADD)
    {
        ulong dealTicket = trans.deal;
        if(HistoryDealSelect(dealTicket))
        {
            long magic = HistoryDealGetInteger(dealTicket, DEAL_MAGIC);
            if(magic != MAGIC_NUMBER) return;  // 非本EA的交易，忽略
            
            long   dealType = HistoryDealGetInteger(dealTicket, DEAL_TYPE);
            double price    = HistoryDealGetDouble(dealTicket, DEAL_PRICE);
            double volume   = HistoryDealGetDouble(dealTicket, DEAL_VOLUME);
            
            Print("✅ 成交确认：", 
                  (dealType == DEAL_TYPE_BUY) ? "买入" : "卖出",
                  " 价格：", price, " 手数：", volume);
            
            // 更新内部状态
            UpdatePositionState();
        }
    }
}

风险：OnTradeTransaction在交易线程中被调用，执行时间会阻塞其他交易操作。因此不要在里面做耗时操作（如复杂的循环计算、文件读写等）。正确的做法是：在回调中只做快速的状态标记或数据记录，把实际处理逻辑放到OnTick中执行。

模块5：异常订单自动处理

止损没设上的"裸单"、挂单卡了很久没成交、持仓手数异常——这些"遗漏"在实盘中很常见，但每一个都可能造成严重亏损。我们需要一个定期扫描和自动修复机制。

void CheckAndFixAbnormalPositions()
{
    for(int i = PositionsTotal() - 1; i >= 0; i--)
    {
        ulong ticket = PositionGetTicket(i);
        if(PositionGetInteger(POSITION_MAGIC) != MAGIC_NUMBER) 
            continue;
        
        double   sl       = PositionGetDouble(POSITION_SL);
        double   tp       = PositionGetDouble(POSITION_TP);
        datetime openTime = (datetime)PositionGetInteger(POSITION_TIME);
        
        // 检查1：止损是否设置（裸单检测）
        if(sl == 0 || sl == EMPTY_VALUE)
        {
            Print("⚠️ 发现裸单！Ticket:", ticket, 
                  " 正在设置紧急止损...");
            double currentPrice = PositionGetDouble(POSITION_PRICE_CURRENT);
            double point = SymbolInfoDouble(_Symbol, SYMBOL_POINT);
            long   digits = SymbolInfoInteger(_Symbol, SYMBOL_DIGITS);
            
            // 紧急止损：距当前价100点
            double emergencySL = NormalizeDouble(
                currentPrice - 100 * point, (int)digits);
            
            CTrade trade;
            trade.SetMagicNumber(MAGIC_NUMBER);
            trade.PositionModify(ticket, emergencySL, tp);
        }
        
        // 检查2：挂单超龄（超过N小时未成交）
        // 检查3：持仓时间异常长
    }
}

重点：裸单检测是实盘EA的安全底线。无论策略多么可靠，只要有一笔止损没设上的订单，一次极端行情就可能造成不可接受的损失。我们交付的每一个EA都包含完整的异常订单检测与修复模块，确保没有"裸单"风险。

操作参考：将CheckAndFixAbnormalPositions()放在OnTimer()中，每30秒执行一次。需要在OnInit()中调用EventSetTimer(30)启用定时器。紧急止损的距离（示例中100点）应根据品种波动特性调整——外汇主流货币对可设50-100点，黄金/原油等波动大的品种设200-500点。

模块6：日志分级系统

Print满屏都是，关键时刻找不到有用的错误信息。一个分级日志系统能大幅提升调试效率。

enum LOG_LEVEL { LOG_ERROR = 1, LOG_WARN = 2, LOG_INFO = 3, LOG_DEBUG = 4 };
input LOG_LEVEL InpLogLevel = LOG_INFO;

void Log(LOG_LEVEL level, string msg)
{
    if((int)level > (int)InpLogLevel) return;
    
    string prefix = "";
    switch(level)
    {
        case LOG_ERROR: prefix = "❌ [ERROR] "; break;
        case LOG_WARN:  prefix = "⚠️ [WARN] ";  break;
        case LOG_INFO:  prefix = "ℹ️ [INFO] ";  break;
        case LOG_DEBUG: prefix = "🔍 [DEBUG] "; break;
    }
    Print(prefix, TimeToString(TimeCurrent(), TIME_DATE|TIME_SECONDS), " ", msg);
}

知识点：日志级别从低到高：ERROR（1）→ WARN（2）→ INFO（3）→ DEBUG（4）。设为LOG_INFO时，只输出ERROR、WARN、INFO三种级别的日志，DEBUG不会输出。实盘建议设为LOG_INFO，只在需要排查问题时临时切换到LOG_DEBUG。

模块7：EA状态持久化

MT5重启或VPS重启后，EA的所有全局变量全部丢失——日内盈亏、连续亏损次数、上次交易时间等信息全没了。用GlobalVariable做状态持久化，让EA重启后能"记住"关键状态。

// 保存关键状态
void SaveState()
{
    GlobalVariableSet("EA_DailyPnL", m_dailyPnL);
    GlobalVariableSet("EA_LastTradeTime", (double)m_lastTradeTime);
    GlobalVariableSet("EA_ConsecutiveLosses", (double)m_consecutiveLosses);
}

// 恢复状态
void LoadState()
{
    if(GlobalVariableCheck("EA_DailyPnL"))
        m_dailyPnL = GlobalVariableGet("EA_DailyPnL");
    if(GlobalVariableCheck("EA_LastTradeTime"))
        m_lastTradeTime = (datetime)GlobalVariableGet("EA_LastTradeTime");
    if(GlobalVariableCheck("EA_ConsecutiveLosses"))
        m_consecutiveLosses = (int)GlobalVariableGet("EA_ConsecutiveLosses");
    Print("✅ EA状态已恢复");
}

EA系统健康监控与状态管理示意

进阶原理：GlobalVariable是MT5客户端级别的持久化存储，数据存储在终端目录的global_variables.dat文件中。它的特点是：①重启MT5后数据仍在；②不同EA之间可以通过GlobalVariable共享数据（但要注意命名冲突，建议加EA前缀）；③只支持double类型，其他类型需要转换。在关键操作后调用SaveState()，在OnInit中调用LoadState()，形成完整的状态保存/恢复闭环。

模块8：全局看门狗

EA某个环节卡住了——死循环、资源锁、句柄失效——整个EA停摆，没有任何输出。看门狗定时器定期检查EA是否还在正常运行，异常时自动恢复。

// 在OnInit中启用定时器
EventSetTimer(30);  // 30秒触发一次

void OnTimer()
{
    // 更新心跳
    static datetime lastHeartbeat = 0;
    lastHeartbeat = TimeCurrent();
    
    // 每30秒：检查异常持仓
    CheckAndFixAbnormalPositions();
    
    // 每5分钟：保存状态（用计数器模拟）
    static int tickCount = 0;
    tickCount++;
    if(tickCount % 10 == 0)  // 10×30秒=5分钟
        SaveState();
    
    // 每1小时：检查句柄健康
    if(tickCount % 120 == 0)  // 120×30秒=60分钟
        CheckHandleHealth();
}

操作参考：看门狗定时器是长时间运行EA的运维保障。建议的定时任务分配：30秒——异常持仓检查（高频，保障安全）；5分钟——状态持久化（中频，避免频繁写入）；1小时——句柄健康检查（低频，句柄一般不容易出问题）。在OnDeinit中调用EventKillTimer()关闭定时器。

8个模块的集成优先级

不需要一次性把8个模块全集成到EA里。按优先级逐步添加，先把最关键的做好：

优先级	模块	原因
🔴 P0必须	交易重试 + 句柄泄漏防护	没有这两个，EA根本跑不稳
🟡 P1重要	网络断连恢复 + 异常订单处理	实盘必备的安全网
🟢 P2推荐	OnTradeTransaction + 日志分级	提升效率和可调试性
🔵 P3加分	状态持久化 + 看门狗	长时间运行的稳定性保障

进阶原理：容错机制的本质是"假设一切都会出错"。网络会断、服务器会拒绝、句柄会泄漏、状态会丢失——实盘环境中，任何可以出错的环节都会出错。好的容错机制不是消除错误（这不可能），而是让EA在出错后能自动恢复到正常状态，而不是直接"死掉"或做出错误决策。

重点：EA的策略决定能赚多少，容错机制决定能活多久。一个策略一般但容错完善的EA，长期收益大概率优于策略出色但"裸奔"的EA。因为后者总有一天会遇到一个无法处理的异常，导致一笔灾难性的亏损。

本文所有8个容错模块的代码均可直接复制集成到你的EA中。建议按P0→P1→P2→P3的优先级逐步添加，每个模块独立测试通过后再集成下一个。长时间运行的EA需要完善的运维机制，我们的EA定制服务包含完整的状态持久化和自动恢复功能。

风险：容错机制能显著降低EA因技术故障导致的损失，但无法消除所有风险。市场风险、策略风险、经纪商风险等不在本文讨论范围内。容错机制是EA的"安全带"，但安全带不能防止车祸——它的作用是在事故发生时减轻伤害。

📦 免费领取《EA容错机制代码模板包》

包含：8个完整容错模块 + 错误代码速查表 + 稳定性自检Checklist

扫码添加晓辉编程微信，回复【容错】免费领取 ↓

🎬 关注晓辉编程视频号

MT4/MT5 EA开发实战 | 技术方法探讨 | 编程技巧干货

微信搜索：晓辉编程

💬 添加晓辉为好友

一对一交流EA开发 | 定制需求咨询 | 进技术交流群

微信号：XiaoHuiProgramming