MQL4（64）：如何调试你的EA

每一位程序员，无论新手还是专家，其大部分时间都不是在写新代码，而是在调试。这并非失败的标志，恰恰是编程这门手艺的精髓。调试，就是侦探工作：我们根据线索，建立假设，最终找到并修复系统中的罪犯(Bug)。

在MQL4中，我们缺少花哨的现代调试工具。我们的“侦探工具箱”里，最核心、最强大的工具，只有一个——Print()函数。今天，你将学会如何成为一名MQL4的“神探”。

第一部分：策略回测中的“逻辑侦探”

EA最常见的错误，是策略逻辑与我们的预期不符。排查这类问题的最佳场所，就是策略测试器。

• 策略测试器是我们的“犯罪现场模拟器”，可以反复回放市场行情。
• Print()函数就是我们的“指纹采集工具”。通过在代码的关键位置，策略性地安插Print()语句，打印出当时的变量值、指标值或判断条件，我们就能清晰地追踪到代码的实际执行路径，让隐藏的逻辑错误无所遁形。
• Print()输出的信息，会显示在策略测试器下方的“日志”选项卡中。如果信息太多被覆盖，你可以直接在日志窗口右键 -> “打开”，来查看完整的.log日志文件。

案例分析：经典的“错误130”

假设，我们的EA在每次尝试下单时，都返回错误130 (invalid stops – 无效的止损/止盈)。我们知道，这通常意味着SL/TP价格设置有问题。

这是我们有问题的代码：

if(Close[0] > MA && BuyTicket == 0)
{
    double OpenPrice = Ask; 
    double BuyStopLoss = OpenPrice + (StopLoss * UsePoint); // 此处可能存在问题
    double BuyTakeProfit = OpenPrice + (TakeProfit * UsePoint); // UsePoint 假设是点值转换因子
    BuyTicket = OrderSend(Symbol(), OP_BUY, LotSize, OpenPrice, UseSlippage,
                          BuyStopLoss, BuyTakeProfit, "Buy Order", MagicNumber, 0, Green);
    SellTicket = 0; // 重置卖单订单号
}

为了诊断问题，我们在OrderSend()之前，加上一行代码：

Print("Price:", OpenPrice, " Stop:", BuyStopLoss, " Profit:", BuyTakeProfit);

运行回测后，我们查看日志，发现了如下记录：

11:52:12 2009.11.02 02:00 Example EURUSD,H1: OrderSend error 130
11:52:12 2009.11.02 02:00 Example EURUSD,H1: Price:1.47340000 Stop:1.47840000 Profit:1.47840000

日志清晰地显示，对于一个开仓价为1.4734的买单，我们计算出的止损价1.4784竟然比开仓价还高！这显然违反了“买单止损必须在开仓价之下”的交易规则。回看代码，我们立刻就定位到了罪魁祸首——计算BuyStopLoss时，我们把减号-误写成了加号+。

正确的代码应该是：

double BuyStopLoss = OpenPrice - (StopLoss * UsePoint); // 买单止损应为开仓价减去止损点数

常见逻辑错误代码速查：

• 错误129：无效价格。检查你的挂单价格是否离市价太近，或者市价单是否用了正确的Ask/Bid。
• 错误130：无效止损/止盈。检查你的SL/TP是否满足“买单SL<开仓价
• 错误131：无效交易量。检查你的手数是否满足经纪商的最小、最大和步长限制。

第二部分：真实交易中的“偶发事件调查员”

有些Bug很“狡猾”，只在真实的、混乱的实时交易环境中才会偶尔出现。对于这类问题，我们需要一个“实时监控系统”。

方法就是，在EA的外部参数中，加入一个“调试模式”开关。

// 外部输入变量
extern bool DebugMode = true; // true表示开启增强型日志，false表示关闭

然后，在OnTick()函数的末尾，加入一段详细的日志记录代码：

if(DebugMode == true)
{
    Print(StringConcatenate("Bid:", Bid, " Ask:", Ask, " MA:", MA_Value, // 假设MA_Value是指标值
                            " BuyTicket:", BuyTicket, " SellTicket:", SellTicket));
}

当DebugMode为true时，EA会在每个决策点，都把当时的市场价格、指标值、内部变量状态等所有“现场信息”都记录下来。这样，当未来某个异常交易发生时，我们就能通过查阅这些详尽的日志，完整复盘EA当时的“所见所想”，从而定位问题。

学长建议：为了避免日志文件过快膨胀，最好将这段调试代码也放在“新K线生成时”的判断块内，让它只在每根K线开始时记录一次。

第三部分：编译期的“语法老师”

这类错误最简单，它甚至不让你的EA运行。当你点击“编译”时，编译器这位严格的“语法老师”会检查你的代码，并把所有语法错误都列在下方的“错误”窗口。

编译错误处理的黄金法则：永远只看第一个错误！

当编译器给你列出50个错误时，不要惊慌。你真正的问题，往往只是列表中的第一个错误。一个遗漏的分号，就可能让“老师”完全误解你后面的所有句子，从而引发一连串的“连锁报错”。 修复第一个错误，再点一次编译，你会惊奇地发现，剩下的49个错误可能就这么神奇地消失了。

常见编译错误“错题本”：

• variable not defined (变量未定义)：用了一个变量，但忘了声明（忘了写int, double等），或者单词、大小写拼错了。
• variable already defined (变量重复定义)：在同一个地方，声明了两次同名变量。比如写了两次int i = 0;。
• function is not defined (函数未定义)：调用的函数名写错了，或者忘了用#include引入包含它的文件。
• illegal assignment used (非法赋值)：这是个“无声的杀手”！在需要比较是否相等的if判断里，把==误写成了赋值的=。例如if(a = 5)，这句代码的本意是“如果a等于5”，但实际效果是“把5赋值给a，然后判断条件永远为真”，会导致灾难性的逻辑错误。
• unbalanced right/left parenthesis (括号未配对)：多写或少写了( )。耐心检查你写的复杂if语句或计算公式。
• semicolon expected (缺少分号)：在某条语句的末尾，忘了写英文分号;。这是最高频的错误，也是最容易引发连锁报错的错误。

掌握调试，就是掌握了与代码沟通的艺术。保持耐心，像侦探一样思考，每一个被你亲手修复的BUG，都将成为你迈向编程高手的坚实阶梯。