精通日志记录（第一部分）：MQL5中的基础概念与入门步骤（基础篇）
「MT5里先把日志开关打开」
想在 MQL5 里做价格行为复盘，第一步不是写策略，而是确认终端把日志吐出来。MT5 默认会在「专家」「日志」两个标签页记录 EA 与脚本运行信息，但很多人只在图表上看箭头，从不去翻这两栏，等到报错就抓瞎。 打开 MT5，按 Ctrl+T 调出终端，切到「专家」页；若运行了 EA 却无任何输出，先检查 EA 属性里「允许算法交易」和「加载时启用」是否勾上。2025-07-17 发布的示例里，一个空 EA 在 EURUSD 的 M1 上跑 720 根 K 线，终端「专家」页稳定打印了 720 条 tick 时间戳，说明基础日志链路是通的。 新手常犯的是把 Print() 当万能，却不知道它只在「专家」页出现，不写文件就重启即丢。外汇与贵金属杠杆高、跳空频繁，靠记忆复盘胜率纯属赌运气，让小布替你跑这套日志链路，比肉眼盯盘靠谱得多。
◍ 为什么要从零造一个MQL5日志库
MT5终端自带的日志能覆盖启动、服务器连接、环境信息这类基础监控，但本质上不是为EA运行期行为设计的。当你想追溯某次下单失败的具体上下文、采样策略函数的耗时、或者按模块隔离调试输出时，原生日志缺乏精度、控制力和定制维度。 本系列不照搬现成框架，而是从0搭一套可定制的日志系统：你能决定记录哪些关键事件、如何追踪错误、是否做性能采样，以及把特定信息落盘供后续排查。起点是先想清楚“为何记”，再落到“怎么记”。 外汇与贵金属EA回测和实盘差异大，日志若缺失执行上下文，复盘胜率归因会很困难。高风险品种下，可控的日志是降低盲调成本的基础设施，而非锦上添花。
EA 的沉默目击者：日志到底记了什么
在 MT5 里跑 EA，日志就是系统和程序按时间顺序吐出来的事件流。每一次下单请求、每一个报错、每一回决策分支，都会被写成一行文本留在后台。没有它，你复盘一次异常成交就像摸黑走迷宫，根本不知道卡在哪一环。 一个典型故障场景：EA 突然开始批量丢请求，服务器返回拒绝。没结构化日志时你只能瞎猜——是券商限流还是参数填错？而设计得当的日志能直接把‘针’从‘干草堆’里拎出来，比如明确标出 authentication failed、timeout 或 request overflow。 日志行通常带四块信息：时间戳（精确到毫秒级，定位事件顺序）、事件类型（error / warning / info / debug）、描述文本、以及附加上下文（当时的变量值、图表周期、交易品种）。打开 MT5 终端的 Experts 或 Journal 标签，随便点开一个 EA 的运行记录，对照这四列就能看懂它当天的全部行为轨迹。 但日志不是越多越好。无差别打印会让无关数据堆积、存储成本上升，还可能把账户敏感信息写进去。外汇与贵金属自动交易本身高风险，日志若配得乱，本来该当地图用的东西会变成噪声，反而误导判断。
「EA日志能替你盯住的四个死角」
在 MT5 里跑 EA，最怕的不是行情反向，而是错误发生得无声无息。结构化的日志等于给 EA 装了一支录音笔：哪里崩、为什么崩、当时发了什么参数，全留痕。
调试阶段最直观。上面这段日志里，2024-11-18 14:32:15 报出 10015（TRADE_RETCODE_INVALID_PRICE），明确指向限价买入请求的价格字段非法。没有这行，你大概率归咎于『偶尔连不上』，而有了它，开发者直接定位到下单环节的价格拼接逻辑。
审计与合规层面，日志是金融系统里少有的硬凭证。谁在何时发了什么订单、服务器回了什么，逐条可查；异常访问不再是模糊猜测，而是能从时间序列里直接揪出来。
性能监控别忽视。同一段样本里有一条 Duration: 49 ms 的成交回执，以及 CPU usage exceeded 90% 的 FATAL——前者看执行效率，后者看资源水位。生产环境里响应时间和错误率持续偏高，往往就是该重构代码的信号。
日志还能接自动化警报。把关键字（如 FATAL、10015）挂到邮件或短信网关，EA 一出事你手机先响，不用等账户莫名回撤才发现。外汇与贵金属杠杆高、滑点突发，这类实时通知能压住小故障演变成大亏损的概率。
[class="num">2024-class="num">11-class="num">18 class="num">14:class="num">32:class="num">15] ERROR : Limit Buy Trade Request Failed - Invalid Price in Request [class="num">10015 | TRADE_RETCODE_INVALID_PRICE] [class="num">2024-class="num">11-class="num">18 class="num">16:class="num">45:class="num">23] INFO - Server response received, EURUSD purchase executed successfully | Volume: class="num">0.01 | Price: class="num">1.01234 | Duration: class="num">49 ms [class="num">2024-class="num">11-class="num">18 class="num">19:class="num">15:class="num">50] FATAL - CPU usage exceeded class="num">90%, immediate attention required.
◍ 先框定日志库要扛的活
动手写 MQL5 日志库之前，先把需求钉死，能少走回头路。这个库不是简单写文件，而是要成为 EA 开发者在 MT5 里统一管日志的底盘。 单例模式必须落地：所有调用方拿到的都是同一个日志对象，避免多实例各写各的、资源重复。数据库存储是硬需求，日志进表才能回头查历史、做审计、找行为模式。 输出方式要分叉——控制台、终端、文件、数据库四路可切换，不同场景用不同通道。日志级别分五档：DEBUG 调细节、INFO 跑行情常态、ALERT 提示非紧急异常、ERROR 局部出错但能续命、FATAL 直接中断执行。 自定义格式不能少，下方代码就是一条基础模板，字段顺序和占位符都可直接改。日志轮转按天或按文件大小切分，防无限膨胀。动态元数据走 JSON 列，把 EA 当时特有上下文塞进去。 FATAL 级自动发通知（邮件 / SMS / 终端警报），确保责任人秒知。还要能测代码段耗时，定位性能瓶颈。这些点就是后面逐篇实现的骨架。 ([{timestamp}] {level} : {origin} {message}) 这条格式里，timestamp 取 MT5 本地时间，level 填五级枚举，origin 标调用模块，message 为正文；渲染层按此拆分即可。
([{timestamp}] {level} : {origin} {message})