EA错误恢复机制设计实战：断线重连、拒单重试与部分成交处理的代码实现方案
EA错误恢复机制设计实战：断线重连、拒单重试与部分成交处理的代码实现方案
做过一段时间的EA托管，你会发现一个规律：策略逻辑写得再漂亮，真正让账户出问题的往往不是方向判断，而是执行环节的意外。断线重连后仓位状态不明、订单被经纪商拒绝却没有日志、部分成交后剩余挂单悬在半空——这些场景单次影响不大，累积起来却足以把一套正期望的策略拖成负期望。有经验的开发者会把错误恢复当成策略的一部分来设计，而不是等报错出现再去补。
这篇从工程实现角度，讲断线、拒单、部分成交三类高频异常的恢复机制怎么搭。代码用伪逻辑表达，重点在结构，不在语法。
断线重连：先确认状态，再谈恢复
网络中断本身不可怕，可怕的是重连之后终端对持仓的认知和服务器不一致。MT4/MT5的终端在断线期间不会丢失本地订单记录，但成交回报可能缺失，这就是状态漂移的源头。
恢复的核心原则只有一条：以服务器持仓为准，本地记录只作参考。重连触发后不要急着补单，先拉一次全量对账。
- 调用 OrdersTotal / PositionsTotal 遍历当前持仓与挂单，建立服务器侧快照
- 读取本地持久化文件或全局变量中的策略预期状态
- 逐条比对：缺失的持仓、多余的持仓、数量不符的持仓分别标记
- 数量不符的走差异处理流程，缺失的按策略规则决定补开还是放弃
伪代码逻辑大致如下：
OnReconnect():
serverState = SnapshotPositions()
localState = LoadStateFromFile()
diff = Compare(serverState, localState)
if diff.hasMissingPosition:
if StrategyAllowsReentry(): OpenPosition(diff.missing)
else: MarkAsAbandoned(diff.missing)
if diff.hasExtraPosition: FlagForManualReview(diff.extra)
注意：重连后的补单必须加时间窗限制，比如断线超过N分钟就只对账不补单。行情已经走远，补进去的仓位和原计划的风险敞口完全是两回事。这个N建议按策略持仓周期设定，日内策略可以收紧到几分钟级别。
拒单不是失败，是需要分类的信号
订单被拒的原因五花八门，但处理方式其实可以归成几类。把所有拒单都当成同一种错误重试，是很多EA在实盘里反复触发风控的根源。
按返回码分类处理：
- 价格类拒单（如报价无效、滑点超限）：可重试，但要重新获取报价并放宽容忍度，重试次数设上限，比如3次后放弃并记录
- 资金类拒单（保证金不足）：不可重试，应缩减手数或跳过本次信号，同时触发账户风险检查
- 参数类拒单（手数不合法、止损距离不合规）：不可重试，属于配置问题，直接写日志告警
- 频率类拒单（下单过于频繁）：退避重试，间隔递增
实现上建议做一个返回码映射表，把经纪商返回的retcode映射到上述四类，策略层只处理类别，不处理具体码值。这样换平台时只需要改映射表，不用动策略主体。各经纪商的返回码定义以官方文档为准，不同平台在参数校验的严格程度上确实存在差异，比如最小止损距离和手数步长的处理，这块在部署前要实测确认。
部分成交：最容易被低估的坑
部分成交在流动性好的主流品种上不常见，但一旦出现，处理不当会直接导致策略逻辑错乱。典型场景是：计划开1手，实际成交0.4手，剩余0.6手挂在市场上，EA却按1手在算止损和止盈。
恢复机制要解决两件事：确认实际成交量，以及决定剩余部分怎么处理。
成交回报到达后，立即读取实际成交量并更新内部持仓记录，所有后续的止损、止盈、加仓计算都基于实际量重算。剩余挂单的处理分两种策略：
- 激进型：保留挂单等待继续成交，但设置超时，超时未成交则撤单
- 保守型：立即撤掉剩余挂单，按已成交量重新计算风险敞口，不足最小手数的直接平掉
选哪种取决于策略对仓位精度的敏感度。网格类策略对仓位精度要求高，建议走保守型；趋势跟踪类可以接受仓位偏差，激进型更合适。这个选择要写进参数配置，不要硬编码。
参数配置与回测验证
恢复机制的参数建议单独抽成一个配置块，方便回测时做敏感性测试。示例参数如下，非真实回测结果：
- ReconnectTimeoutMinutes = 5（断线超过此时长只对账不补单）
- MaxRetryPerOrder = 3（单笔订单最大重试次数）
- RetryBackoffSeconds = 2（重试间隔基数，按次数递增）
- PartialFillPolicy = CONSERVATIVE（部分成交处理策略）
- PartialFillTimeoutSeconds = 30（激进型下的挂单超时）
回测层面，策略测试器本身很难模拟断线和拒单，这部分要靠自建模拟环境。做法是在代码里注入故障开关，比如按概率触发拒单返回、按概率截断成交量，然后在测试器里跑一遍完整周期，观察恢复逻辑是否按预期执行。评价指标不看收益，看的是状态一致性：每笔交易结束后，本地记录与模拟服务器持仓是否完全吻合。数据区间建议覆盖至少一个完整的波动周期，参数扫描重点放在重试次数和超时阈值上。
部署时的一个细节
恢复逻辑依赖状态持久化，写文件的时机很关键。每次成交后立即写，不要等OnDeinit。终端崩溃或VPS重启时，OnDeinit不一定执行，状态文件就会停留在旧版本。写入用临时文件加原子替换的方式，避免写到一半断电导致文件损坏。
VPS选型上，恢复机制对延迟的容忍度其实不高，重连越快，状态漂移窗口越小。机房位置尽量靠近经纪商服务器，这个比CPU核数重要得多。
新手最容易忽略的一环，是恢复逻辑本身的日志。断线、拒单、部分成交的处理过程如果没有完整记录，出问题时你根本不知道EA当时看到了什么、做了什么判断。日志要记录原始返回码、对账差异、采取的动作用以及时间戳，这些是事后复盘的唯一依据。恢复机制写得再好，没有日志就等于黑箱。
你在部署EA时遇到过断线后状态不一致的情况吗？留言交流具体的排查思路。
免责声明：本文仅代表作者观点，不构成任何投资建议。市场有风险，交易需谨慎。
