EA日志设计：让事故事后可以复现

结论：没有日志的EA，出了事故也无从验证

先说结论。EA的日志至少应当各用一行输出三类信息：「判断所用的数值」「没有入场的原因」「成交的结果」。有了这三类，就能在事后复现意外的交易，以及「什么都没发生」的情况。反过来，如果没有这些，无论是出现亏损，还是交易数一直为0，你都无法分清原因究竟出在EA的逻辑、行情，还是经纪商一侧。

我们自己开发EA时，既有被日志救了一命的时候，也有因为日志不足而始终没查清原因的时候。本文从使用EA的一方出发，梳理什么才是「好的日志」。

为什么需要三类日志

EA的一次判断，大致是「计算数值 → 判定条件 → 下单 → 成交」这样的流程。要在事后确定是哪个环节与预期不符，每个环节都需要有记录。

判断值：不留下数字，就无法与「碰巧」区分

只输出「出现买入信号」的日志，作用很有限。因为不知道当时指标数值与阈值相差多少，就无法判断是勉强满足条件，还是明确满足条件。另外，用哪一根K线(已确认K线的时间)做出的判断，也务必记录下来。

跳过原因：最容易被省略，却最重要的日志

很多EA只在「入场」时才输出日志。然而运行中最常见的疑问恰恰是「完全不入场」。如果日志里有放弃入场的原因，就能确认这是符合设计的放弃，还是由设置错误或服务器时间偏差造成的。

我们的MEGAMAX DONCHIAN在Exness模拟账户上进行前向测试，截至2026年11月11日，交易数为0。放弃入场的原因我们目前也尚未确认，在此不做推测。不过遇到这种情况，有没有跳过原因的日志，会让排查的工作量大不相同。交易数为0并不意味着业绩不佳，但在读过日志之前，也不能断言这就是「正常的放弃」。

成交：记录发生在EA之外的事

订单是被拒绝了，还是成交了但滑点很大，这与EA的逻辑是两回事。只要留下返回码和成交价格，就能把EA自身的问题与经纪商、网络线路的问题分开考虑。

每行输出什么：写法示例

我们把一次判断汇总为一行，并采用便于事后检索的固定格式。

[EVAL] bar=2026.11.10 14:00 sig=BUY val=1.234 th=1.200 spread=18 -> ENTRY
[SKIP] bar=2026.11.10 15:00 reason=SPREAD spread=45 max=30
[FILL] ticket=123456 req=152.340 fill=152.346 slip=6 ret=10009

写的时候要注意以下几点：

• 行首加上类型标签(EVAL / SKIP / FILL)，方便用grep或搜索提取
• K线时间写「用于判断的已确认K线」的时间(以服务器时间为前提)
• 原因不用句子，而用固定代码书写(SPREAD、TIME、POSITION 等)
• 不要每个tick都输出，只在做出判断的那一刻输出

如果每个tick都输出，日志会在短时间内变得极其庞大，既占用磁盘，也会把关键的行淹没。基本原则是「K线确认时输出一次」。

使用者的检查步骤

使用EA的人按下面的顺序检查，能更快找到原因。

1. 在MT5的「专家」选项卡中，确认EA是否在输出自己的日志
2. 找到出现意外交易那一时刻的EVAL行，查看判断值和阈值
3. 对于没有入场的时间段，查看SKIP行，统计哪种原因最多
4. 在FILL行中，确认请求价格与成交价格的差异以及返回码
5. 将「操作历史」选项卡(经纪商一侧的记录)与时间进行比对

设置的复查可参考EA设置方法，24小时稳定运行的环境搭建可参考VPS信息。

局限与注意事项

日志并非万能。我们在此如实说明。

• 日志里没写的东西就无从得知。 开发者没有预想到的情况，本来就不会被记录。
• 日志不一定正确。 如果输出日志的代码本身有bug，记录下来的就是错误的数值。
• 看不出行情判断的好坏。 日志只能告诉你「是否按设计运行」，而不能告诉你按这个设计能不能赚钱。
• 输出过多同样会酿成事故。 大量日志会挤占容量，阅读的人也更容易漏看。
• 回测与模拟账户、真实账户中，日志的含义不同。 策略测试器无法像真实环境那样重现滑点和订单拒绝，对比成交日志时请以环境存在差异为前提。

总结

• 日志中各用一行输出「判断值」「跳过原因」「成交」三类信息
• 最容易被省略的是放弃入场原因的日志，排查「EA不动」的原因时它最有用
• 事先定好标签和原因代码，事后就可以检索并统计
• 输出以每根已确认K线一次为准，不要每个tick都输出
• 日志只能说明「是否按设计运行」，能否盈利需要另外验证

其他MT5运维经验汇总在EA・MT5知识库中。