EA跑回测正常，实盘却报134，是VPS时钟同步漂移在作怪吗？

前两天一个汇友私信我，说他那套做欧美M15的EA回测三年数据漂漂亮亮，一上实盘就频繁报134，问我是不是VPS时钟漂移搞的鬼。这个问题我去年自己也踩过一次，当时折腾了两天才定位到，今天就把排查思路完整捋一遍。
先说结论：134是“Not enough money”，不是时钟问题。很多人一看到实盘和回测表现不一致，第一反应就是怀疑VPS时间同步，因为时钟漂移确实会导致K线时间戳错乱、指标计算偏移，但那类问题的报错通常是4060（无连接）或4109（交易不允许），跟134完全不是一回事。134的官方定义就是可用保证金不足，订单被服务器拒绝。
那为什么回测不报？因为回测时用的是历史数据加静态点差，而且多数人测的时候账户是全额虚拟资金，不涉及真实保证金占用逻辑。实盘报134，我总结下来一般卡在三个地方：

• 手数计算没考虑挂单占用的保证金。我那个案例就是同时挂了两个Buy Limit，EA只判断了余额够不够开新单，没算已挂订单的冻结保证金，结果第二单直接被拒。
  
• 杠杆跟回测环境不一致。回测默认用的可能是1:500，实际账户是1:100，保证金需求翻了五倍，同样的手数就爆了。
  
• 点差和滑点没预留缓冲。欧美在数据公布前后点差能拉到3-5个点，保证金按实时点差算，开仓瞬间就不够了。
  

排查步骤我是这么走的：
第一步，先把MT4的日志调出来，不是看EA面板，是看终端里“交易”标签页的原始报错。134后面通常会跟一行可用保证金和所需保证金的数值，拿这两个数一比就知道差多少。
第二步，在EA里加一段保证金预检。我现在的写法是在OrderSend之前调MarketInfo拿保证金需求，加上20%的缓冲再判断，简单几行代码就能挡掉大部分134。别用AccountFreeMargin直接判断，那个是静态值，遇到点差扩大会失效。
第三步，核对VPS和经纪商服务器的时间。这一步不是为了解决134，但能顺手排掉其他坑。我一般用命令行跑w32tm /stripchart看偏移，超过2秒就该让VPS商处理了。时钟漂移影响的是EA的定时逻辑和News Filter，跟保证金无关，但排查时容易混淆方向。
第四步，如果上面都排了还报，那就去看经纪商的保证金计算方式。有些平台是净额对冲，有些是锁仓占用双倍保证金，换平台跑同一套EA结果可能完全不同。
我自己的结论是：EA实盘和回测对不上，先分清楚是环境差异（点差、杠杆、执行延迟）还是代码逻辑漏洞（保证金预检、订单重试），绝大部分134都是后者。VPS时钟同步是另一个独立问题，别把它当万能背锅侠。
你们跑EA的时候有没有遇到过134跟其他报错混在一起的情况？最后是怎么定位到根因的，评论区聊聊。

补充一句：还有种情况是账户开了对冲模式，多空双向持仓保证金按较大一边算，回测默认净持仓根本模拟不出来，这个坑也挺隐蔽的。