先修第一条有根因的错误
EA 编译错误表示源码未满足当前编译器要求。MQL 编译报错常由语法、未声明名称、类型或函数签名不匹配、缺失依赖引起；前面的错误会引发后续连锁提示。先保存完整错误列表，再从第一条与实际文件对应的错误定位，不同时删除多段交易逻辑。
确认 MetaEditor 编译的是目标文件
用目标 MT4 或 MT5 对应的 MetaEditor 打开准确的 .mq4 或 .mq5 源码。核对文件路径与保存时间，避免修改了一个副本却编译另一个。MQL4/MQL5 的订单与指标接口不同，把后缀改成另一平台不是修复；迁移需求要作为新版本处理。
缺文件先恢复依赖，不伪造空实现
#include 使用的 .mqh 头文件、库和资源应保持原目录结构。尖括号通常从标准 Include 目录找，双引号先按当前源码所在目录定位；以源码引用和编译器报出的实际路径核对。自定义指标文件也可能是运行依赖，EA 编译通过不表示 iCustom 加载成功。不要用空函数替换未知库后声称功能已恢复。
逐条错误对应具体动作
报错行可能只是编译器无法继续解析的位置，根因可能在前一行的括号、分号或字符串。提供上下文而不是只抄一行提示；修复后重编译，看原错误是否消失以及是否暴露新的独立错误。
| 报错方向 | 先检查什么 |
|---|---|
| cannot open include file | 核对头文件全路径、子目录和依赖包，不直接删除 #include。 |
| undeclared identifier | 核对名称拼写、作用域、声明和目标平台，不随意添加同名变量。 |
| wrong parameters count / type mismatch | 按目标平台核对函数签名、参数类型与返回值。 |
| 语法或括号错误 | 从报错之前的结构开始检查，避免为消除提示改掉条件含义。 |
| 警告 | 核对隐式转换、返回值和精度风险，零错误不意味着警告无关。 |
修复请求示例：保留范围与材料
下面是假设的错误材料示例，不是已修复源码或已执行回测证据。实际报错以目标 MetaEditor 输出为准。
平台：MT5；文件：SessionBreakout.mq5；保留原版
第一条：cannot open include file，指向 SessionRules.mqh
材料：完整错误列表、#include 路径、项目目录结构、附近源码
目标：恢复合法依赖并修复引用；不改入场、仓位和止损规则
验收：重新编译记录错误/警告；再检查初始化和相同配置下的行为编译通过后还有执行与规则两关
保留修改前后文件、差异、编译器环境和错误列表。编译通过只解决编译阶段，指标加载、交易返回码、信号时机与止损仍要检查。把修复版提交到修改流程时明确不得改变的规则，再用固定配置回测和模拟观察；旧报告不能证明新源码。
编译与代码修复常见问题
几十条报错要一次全部修改吗？
先保留全部错误，从第一条有根因的错误开始，逐次重编译。缺失依赖或语法错误可能引发多条连锁提示。
能删除有问题的指标或风控让编译通过吗？
不能把删除功能当成等价修复。确需改变规则时应明确授权范围，形成新版本并单独验证。
编译零错误是不是 EA 已修好？
只说明当前版本通过编译。仍需阅读警告，检查初始化、依赖、信号和交易执行，再进行绑定配置的测试。