MT5 EA打包安装与自动更新系统开发实战

从零搭建EA产品化交付体系——安装包、版本管理、在线更新与回滚机制完整实现

一、EA产品化的最后一块拼图——为什么你需要打包安装系统

如果你是一名EA开发者，或者正在做EA定制业务，问自己一个问题：你的EA写完之后，是怎么交付给客户的？

相信很多人的答案是：编译出ex5文件，微信或邮件发过去，然后告诉客户"把文件放到MQL5/Experts文件夹里，重启MT5就行"。听起来很简单对吧？但实际操作中，你会遇到各种各样的问题——客户找不到文件夹、放错了位置、和MT4路径搞混了、不知道怎么刷新导航器、版本发错了……光是安装指导这一步，就能耗掉你大量时间。

这还只是交付环节。后续的版本更新、Bug修复、新功能迭代，每一次都要重复一遍手动发文件、手动通知客户、手动指导更新的流程。客户多了之后，维护成本会呈指数级上升。

这些问题的根源在于：很多EA开发者只关注"写EA"这件事，把EA写完、编译通过、回测不错，就觉得大功告成了。但如果你想把EA做成一个产品、一个可以商业化交付的东西，"写代码"只是整个产品化流程的第一步。

从"写EA"到"卖EA"，中间隔着一道产品化的鸿沟。这道鸿沟里，有三个核心模块需要补齐，我们称之为"产品化三件套"。

本文作为产品化系列的第二篇（也是收尾篇），将系统讲解"安装部署"和"自动更新"这两个模块的完整实现方案。从安装包结构设计、自解压安装制作，到版本号管理、在线更新检测、增量更新机制、回滚安全网，再到完整系统的搭建和踩坑指南，全链路覆盖。读完这篇文章，你可以直接把文中的方案和代码集成到自己的EA中，搭建一套属于自己的产品化交付体系。

本文配套的4段完整MQL5代码都带有详尽中文注释，兼容MT5 build 4000+版本，读者可以直接复制使用。

二、安装包结构设计——给你的EA一个"标准外壳"

在动手做安装包之前，首先要搞清楚MT5终端的目录结构，知道你的EA文件、指标文件、配置文件分别应该放在哪里。如果路径放错了，客户安装完之后在MT5里找不到EA，整个安装就失败了。

2.1 MT5终端目录结构解析

MT5终端的数据目录结构是有固定规范的，了解这个结构是做好安装包的前提。你可以在MT5中通过"文件→打开数据文件夹"快速定位到数据目录。

需要注意的是，MT5的数据文件夹路径在不同操作系统下是不一样的，而且随着MT5版本的升级也有过变化。这个我们会在后面的踩坑指南里详细说。

2.2 标准安装包目录结构规范

一个标准的EA安装包，不应该只包含一个孤零零的ex5文件。一个完整的产品化安装包，通常包含以下几个部分：

这个结构看起来文件很多，但其实核心就是两件事：第一，EA运行必须的文件（EA本身、依赖指标）放到正确的MT5目录下；第二，产品相关的辅助文件（配置、文档、版本清单、卸载工具）统一放到 MQL5/Files/产品名/ 目录下，方便管理和卸载。

2.3 版本清单文件（manifest.json）设计

manifest.json 是整个更新系统的核心配置文件，也是安装包的"身份证"。它记录了这个版本的所有关键信息，是版本比较、更新检测、回滚验证等功能的基础。

manifest.json 既是安装包里的版本声明文件，也是服务端上的版本信息文件。客户端每次检测更新时，只需要下载服务端的 manifest.json，和本地的做对比，就能知道有没有新版本、哪些文件变了。这个设计非常轻量，一次HTTP请求就能完成版本检测。

2.4 兼容性设计：MT4/MT5双平台支持

很多EA产品同时提供MT4和MT5两个版本，这种情况下安装包需要能够自动识别客户安装的是MT4还是MT5，然后把文件放到对应的目录下。

实现思路也不复杂：安装脚本先检测客户电脑上的终端数据目录，如果同时有MQL4和MQL5两个文件夹，就提示用户选择要安装到哪个平台；如果只有一个，就默认安装到那个。对于EA开发者来说，只需要在安装包里分别放 MT4/ 和 MT5/ 两个子目录，里面放对应平台的编译产物即可。

三、自解压安装程序——让客户双击就能完成安装

有了安装包的目录结构，下一步就是把它做成一个客户双击就能运行的安装程序。对于EA这种体量不大、文件不多的产品来说，使用7-Zip的SFX（自解压）模块是一种性价比较高的方案——免费、轻量、配置灵活，不需要学习复杂的安装制作工具。

3.1 自解压安装包原理

自解压包的原理很简单：就是把一个压缩包和一个解压执行程序（SFX模块）拼在一起，生成一个exe文件。用户双击这个exe文件时，SFX模块会自动把压缩包里的文件解压出来，并且可以在解压前后执行指定的脚本。

对于EA安装来说，我们可以利用这个特性：先把EA文件等内容打包，然后在解压完成后自动执行一个安装脚本，这个脚本负责检测MT5路径、把文件复制到正确位置、刷新终端等操作。这样客户的体验就是"双击exe → 点安装 → 完成"，全程不需要手动找文件夹、不需要手动复制文件。

3.2 安装脚本设计

安装脚本是整个安装过程的"大脑"，它负责完成以下几个核心任务：

1. 检测MT5数据文件夹路径：最常用的方法是读取注册表。MT5安装时会在注册表中记录数据文件夹的路径，安装脚本读取这个注册表项就能拿到准确的路径。如果注册表读不到，再回退到默认路径猜测，或者让用户手动选择。

2. 检查目录是否存在：确认 MQL5/Experts/ 等目标目录存在，不存在则创建。

3. 复制文件：按照manifest.json中的文件列表，把解压出来的文件逐一复制到对应的目标路径。复制前可以先备份已有同名文件，方便出问题时回滚。

4. 写入版本信息：把manifest.json复制到产品目录下，作为本地版本的标识，后续更新检测会用到。

5. 刷新MT5导航器：MT5在运行时不会自动检测新加入的ex5文件，需要用户手动刷新或者重启终端。安装脚本可以在完成后弹出提示，告诉用户"安装完成，请在MT5导航器中右键刷新"。

3.3 安装界面定制与卸载支持

7-Zip SFX支持一定程度的界面定制，比如设置标题、图标、安装提示文字等。对于EA产品来说，建议至少加上自己的品牌Logo和产品名称，让安装包看起来更专业。

四、版本号管理——建立可控的版本迭代体系

版本号是更新系统的基础。没有规范的版本号管理，就没办法判断"哪个版本更新""需不需要升级"。很多EA开发者对版本号很随意，一会儿v1.0，一会儿v2.5，一会儿又v1.8，客户根本搞不清哪个是新的哪个是旧的。

4.1 语义化版本号规范

语义化版本号的好处是，光看版本号就能大概知道这次更新的性质和影响范围。客户看到从1.2.3升到1.2.4，就知道是修Bug，可以放心更；看到升到1.3.0，就知道加了新功能，可以看看更新了什么；看到升到2.0.0，就知道是大版本，可能需要重新配置参数，更新前要做好准备。

4.2 MQL5版本号管理类设计

在MQL5中，版本号不能只是写在注释里，需要能够在代码中读取和使用。比如EA界面上要显示版本号、更新检测时需要拿本地版本号和远程版本号做比较、日志里要记录当前运行的是哪个版本……这些都需要程序能够在运行时获取版本号。

一个实用的做法是写一个 CVersionManager 类，专门负责版本号的管理。这个类要做的事情包括：编译时把版本号嵌入到EA中、运行时提供版本号读取接口、版本号比较功能、版本号格式化输出等。

下面是一个完整的版本号管理类实现，包含了语义化版本号的解析、比较、格式化等核心功能：

//+------------------------------------------------------------------+
//|                                                   VersionManager |
//|                        版本号管理类 - 语义化版本号（SemVer）实现  |
//+------------------------------------------------------------------+
class CVersionManager
{
private:
   int               m_major;          // 主版本号
   int               m_minor;          // 次版本号
   int               m_patch;          // 修订号
   string            m_prerelease;     // 预发布标识（如 alpha、beta、rc.1）
   string            m_build_meta;     // 构建元数据（可选）

public:
                     CVersionManager(void);
                     CVersionManager(int major, int minor, int patch);
                    ~CVersionManager(void);

   // 从字符串解析版本号
   bool              Parse(string version_str);

   // 格式化为字符串
   string            ToString(void);

   // 版本比较：返回 -1 表示当前版本 < other，0 表示相等，1 表示 >
   int               Compare(const CVersionManager &other);

   // 判断是否需要更新（当前版本 < 远程版本返回 true）
   bool              NeedUpdate(const CVersionManager &remote_ver);

   // Getter 方法
   int               GetMajor(void) { return m_major; }
   int               GetMinor(void) { return m_minor; }
   int               GetPatch(void) { return m_patch; }
};

//+------------------------------------------------------------------+
//| 构造函数                                                          |
//+------------------------------------------------------------------+
CVersionManager::CVersionManager(void) : m_major(1), m_minor(0), m_patch(0)
{
   m_prerelease = "";
   m_build_meta = "";
}

CVersionManager::CVersionManager(int major, int minor, int patch)
{
   m_major = major;
   m_minor = minor;
   m_patch = patch;
   m_prerelease = "";
   m_build_meta = "";
}

CVersionManager::~CVersionManager(void)
{
}

//+------------------------------------------------------------------+
//| 从字符串解析版本号                                                |
//| 支持格式：1.2.3 / 1.2.3-alpha / 1.2.3+build123                   |
//+------------------------------------------------------------------+
bool CVersionManager::Parse(string version_str)
{
   if(version_str == "")
      return false;

   // 分离构建元数据（+号后面的部分）
   int plus_pos = StringFind(version_str, "+");
   if(plus_pos >= 0)
   {
      m_build_meta = StringSubstr(version_str, plus_pos + 1);
      version_str = StringSubstr(version_str, 0, plus_pos);
   }

   // 分离预发布标识（-号后面的部分）
   int dash_pos = StringFind(version_str, "-");
   if(dash_pos >= 0)
   {
      m_prerelease = StringSubstr(version_str, dash_pos + 1);
      version_str = StringSubstr(version_str, 0, dash_pos);
   }

   // 解析主.次.修订 三段
   string parts[3];
   int part_count = StringSplit(version_str, '.', parts, 3);

   if(part_count < 2)
      return false;

   m_major = (int)StringToInteger(parts[0]);
   m_minor = (int)StringToInteger(parts[1]);

   if(part_count >= 3)
      m_patch = (int)StringToInteger(parts[2]);
   else
      m_patch = 0;

   return true;
}

//+------------------------------------------------------------------+
//| 格式化为字符串                                                    |
//+------------------------------------------------------------------+
string CVersionManager::ToString(void)
{
   string result = StringFormat("%d.%d.%d", m_major, m_minor, m_patch);

   if(m_prerelease != "")
      result += "-" + m_prerelease;

   if(m_build_meta != "")
      result += "+" + m_build_meta;

   return result;
}

//+------------------------------------------------------------------+
//| 版本比较                                                          |
//| 返回：-1 当前 < 其他，0 相等，1 当前 > 其他                        |
//+------------------------------------------------------------------+
int CVersionManager::Compare(const CVersionManager &other)
{
   // 比较主版本号
   if(m_major < other.m_major) return -1;
   if(m_major > other.m_major) return 1;

   // 比较次版本号
   if(m_minor < other.m_minor) return -1;
   if(m_minor > other.m_minor) return 1;

   // 比较修订号
   if(m_patch < other.m_patch) return -1;
   if(m_patch > other.m_patch) return 1;

   // 版本号主体相同，比较预发布标识
   // 正式发布版本 > 预发布版本（1.0.0 > 1.0.0-alpha）
   if(m_prerelease == "" && other.m_prerelease != "")
      return 1;
   if(m_prerelease != "" && other.m_prerelease == "")
      return -1;

   // 两者都有或都没有预发布标识，视为相等（简化处理）
   return 0;
}

//+------------------------------------------------------------------+
//| 判断是否需要更新                                                  |
//+------------------------------------------------------------------+
bool CVersionManager::NeedUpdate(const CVersionManager &remote_ver)
{
   return (Compare(remote_ver) < 0);
}

这个类的使用很简单：在EA初始化时创建一个实例，用Parse方法把版本号字符串解析进去，后面需要用的时候直接调用ToString()获取版本号字符串，调用NeedUpdate()和远程版本做比较。

4.3 版本号与发布流程的绑定

版本号管理不只是技术问题，也是流程问题。建议建立一个"开发版→测试版→正式版"的晋升机制：

• 开发版（Alpha）：版本号形如 1.2.0-alpha.1，内部开发和自测用，功能可能不完整、Bug较多，不发给客户。
• 测试版（Beta/RC）：版本号形如 1.2.0-beta.1 或 1.2.0-rc.1，发给少数测试用户或者在测试环境运行，验证稳定性。
• 正式版（Release）：版本号形如 1.2.0，经过充分测试后发布给所有用户。

每次发布新版本时，自动生成Changelog（更新日志），记录这一版改了什么、修了什么Bug、加了什么功能。Changelog不仅是给客户看的，也是你自己的版本档案，以后出了问题可以回溯是哪个版本引入的变化。

五、在线更新检测——让EA主动告诉你"该升级了"

有了规范的版本号体系，接下来就要实现在线更新检测功能了。这个功能的目标是：EA启动后，主动去服务器上检查有没有新版本，如果有就提示用户升级。

5.1 更新检测架构设计

这个架构的好处是解耦：版本信息和更新包可以分开存放，版本文件放在主站上方便管理，更新包放在CDN上加速下载。而且版本检测的开销非常小，只是一个HTTP GET请求下载一个小JSON文件，对服务器基本没有压力。

5.2 MQL5中的HTTP请求实现

MQL5中实现HTTP请求有两种常用方式：一种是使用MQL5标准库中的 CWebRequest 类（需要包含 WebRequest.mqh），另一种是直接调用 WinInet 系列Windows API。对于大多数场景，CWebRequest 已经够用了，而且代码更简洁。

下面是一个完整的在线更新检测函数实现：

//+------------------------------------------------------------------+
//|                                                   UpdateChecker |
//|                        在线更新检测函数完整实现                    |
//+------------------------------------------------------------------+
#include 

// 更新检测结果枚举
enum ENUM_UPDATE_RESULT
{
   UPDATE_CHECK_FAILED = -1,   // 检测失败（网络错误等）
   UPDATE_NOT_NEEDED  = 0,     // 不需要更新，已经是最新版
   UPDATE_AVAILABLE   = 1      // 有新版本可用
};

// 更新信息结构体
struct UpdateInfo
{
   string   latest_version;    // 最新版本号
   string   release_date;      // 发布日期
   string   release_notes;     // 更新说明
   string   download_url;      // 下载地址
   bool     is_mandatory;      // 是否强制更新
   long     file_size;         // 更新包大小（字节）
};

//+------------------------------------------------------------------+
//| 在线更新检测函数                                                  |
//| 参数：                                                            |
//|   current_version - 当前版本号字符串（如 "1.2.3"）                 |
//|   manifest_url    - 服务端manifest.json的URL地址                  |
//|   update_info     - 输出参数，返回新版本详细信息                    |
//| 返回值：                                                           |
//|   -1 检测失败 / 0 已是最新 / 1 有新版本                            |
//+------------------------------------------------------------------+
int UpdateChecker(string current_version, string manifest_url, UpdateInfo &update_info)
{
   // 初始化结果
   update_info.latest_version = "";
   update_info.download_url   = "";

   // 创建Web请求对象
   CWebRequest request;

   // 设置超时时间（5秒），避免网络不好时长时间卡住EA
   request.Timeout(5000);

   // 发送GET请求获取服务端版本清单
   string response_body = "";
   int result_code = request.Get(manifest_url, response_body);

   // 检查HTTP响应码
   if(result_code != 200)
   {
      Print("更新检测失败：HTTP错误 ", result_code);
      return UPDATE_CHECK_FAILED;
   }

   if(response_body == "")
   {
      Print("更新检测失败：响应内容为空");
      return UPDATE_CHECK_FAILED;
   }

   // 解析JSON响应（简化版，实际项目中建议使用JSON解析库）
   // 这里用字符串查找做基础解析，演示逻辑
   // 实际使用建议集成json-mql5等开源JSON库

   // 提取最新版本号
   update_info.latest_version = JsonExtractString(response_body, "version");
   if(update_info.latest_version == "")
   {
      Print("更新检测失败：无法解析版本号");
      return UPDATE_CHECK_FAILED;
   }

   // 版本比较
   CVersionManager local_ver;
   CVersionManager remote_ver;

   if(!local_ver.Parse(current_version))
   {
      Print("更新检测失败：当前版本号格式错误");
      return UPDATE_CHECK_FAILED;
   }

   if(!remote_ver.Parse(update_info.latest_version))
   {
      Print("更新检测失败：远程版本号格式错误");
      return UPDATE_CHECK_FAILED;
   }

   // 判断是否需要更新
   if(!local_ver.NeedUpdate(remote_ver))
   {
      return UPDATE_NOT_NEEDED;  // 已经是最新版本
   }

   // 有新版本，提取详细信息
   update_info.release_date  = JsonExtractString(response_body, "release_date");
   update_info.release_notes = JsonExtractString(response_body, "release_notes");
   update_info.download_url  = JsonExtractString(response_body, "download_url");

   // 强制更新标志（可选，manifest中包含此字段时读取）
   string mandatory_str = JsonExtractString(response_body, "mandatory");
   update_info.is_mandatory = (mandatory_str == "true" || mandatory_str == "1");

   return UPDATE_AVAILABLE;
}

//+------------------------------------------------------------------+
//| 简易JSON字符串提取工具函数（演示用）                                |
//| 实际项目建议使用成熟的JSON解析库                                   |
//+------------------------------------------------------------------+
string JsonExtractString(string json, string key)
{
   string search = "\"" + key + "\"";
   int pos = StringFind(json, search);

   if(pos < 0)
      return "";

   // 找到冒号
   pos = StringFind(json, ":", pos);
   if(pos < 0)
      return "";

   // 跳过冒号和空格
   pos++;
   while(pos < StringLen(json) && (json[pos] == ' ' || json[pos] == '\t'))
      pos++;

   // 检查是不是字符串（以引号开头）
   if(json[pos] != '"')
   {
      // 不是字符串，直接读到逗号或右大括号
      int end_pos = StringFind(json, ",", pos);
      int brace_pos = StringFind(json, "}", pos);

      if(end_pos < 0 || (brace_pos >= 0 && brace_pos < end_pos))
         end_pos = brace_pos;

      if(end_pos < 0)
         return "";

      return StringSubstr(json, pos, end_pos - pos);
   }

   // 是字符串，读取到下一个引号（忽略转义）
   pos++;  // 跳过开头的引号
   int end_pos = StringFind(json, "\"", pos);

   if(end_pos < 0)
      return "";

   return StringSubstr(json, pos, end_pos - pos);
}

5.3 更新提示UI与静默更新模式

检测到有新版本之后，怎么通知用户？常用的有两种模式：弹窗提示和静默更新。

弹窗提示模式比较直观：检测到新版本后，用MessageBox弹出一个提示框，显示"检测到新版本 v1.3.0，是否前往下载？"，用户点"是"就打开浏览器跳转到下载页面，点"否"就跳过本次提示。这个模式适合面向普通客户的产品，用户有选择权，也比较安全。

静默更新模式则是在后台自动下载和安装更新，用户完全无感知。这个模式适合团队内部使用的EA，或者用户明确授权自动更新的场景。静默更新的用户体验更好，但风险也更高——如果新版本有Bug，用户还没来得及知道就被更新了，可能会造成更大的影响。

推荐的做法是：默认使用弹窗提示模式，让用户决定要不要更；对于团队内部场景，可以提供一个配置项开启静默更新。

六、增量更新机制——只传变化的，不传全部的

如果你的EA只有几百KB，每次全量更新也没什么问题。但如果EA附带了很多资源文件（指标、配置、文档、图片），整体体积有几MB甚至更大，每次更新都让客户下载完整安装包就有点浪费了——尤其是当这次更新只改了一个文件的时候。

这时候就需要增量更新：只下载变化了的文件，没变的就不动，既省流量又省时间。

6.1 文件差异比对算法

增量更新的基础是文件差异比对。怎么判断两个版本之间哪些文件变了、哪些没变？最常用的方法是基于MD5校验和的比对：

每个版本的manifest.json中，都记录了该版本所有文件的MD5校验和。客户端要更新时，把本地manifest中的文件MD5列表和远程manifest中的做对比——MD5相同的文件就是没变的，不用下载；MD5不同的文件就是变化了的，需要下载新版本。

这个方法简单可靠，实现成本低。对于EA产品这种文件数量不多（通常几十个以内）的场景，完全够用。

6.2 增量包制作与更新流程

增量更新的完整流程分为服务端制作和客户端更新两部分：

服务端增量包制作流程：

1. 准备旧版本和新版本两个完整目录
2. 遍历两个目录中的所有文件，计算MD5校验和
3. 比对MD5列表，找出新增文件、修改文件、删除文件
4. 把新增和修改的文件打包成增量更新包（zip/7z格式）
5. 生成增量版manifest，只包含变化文件的信息
6. 把增量包和增量manifest一起上传到服务器

客户端增量更新流程：

1. 下载远程manifest，与本地manifest对比，确认需要更新
2. 下载增量更新包
3. 校验增量包完整性（MD5校验）
4. 备份所有即将被替换的旧文件到备份目录
5. 解压增量包，替换变化的文件
6. 用新manifest替换旧manifest
7. 验证更新结果：检查所有文件的MD5是否与新manifest一致
8. 验证通过则更新完成，验证失败则执行回滚

你会发现，这个流程里最关键的两个环节就是"备份"和"校验"——备份是为了出问题能回退，校验是为了确保更新是正确的。这两个环节任何一个省掉了，增量更新就是不安全的。

6.3 断点续传与重试机制

对于比较大的更新包，还要考虑网络不稳定的情况——下载到一半断网了怎么办？每次都从头开始下的话，体验会很差。

断点续传的实现思路是：下载过程中记录已经下载了多少字节，如果中途断开，下次下载时从上次断开的位置继续下载。HTTP的Range头支持断点续传，只要服务器端支持Range请求（大多数静态文件服务器都支持），客户端就可以实现断点续传。

另外，网络请求失败后应该有重试机制，比如失败后自动重试2-3次，每次重试的间隔时间逐渐增加（退避策略），避免短时间内频繁重试加重服务器负担。

七、回滚机制——更新出错时的安全网

无论你的更新系统设计得多么完善，都很难保证完全不出问题。新版本可能有Bug、文件可能损坏、客户的环境可能有特殊情况……所以一个成熟的更新系统，必须有回滚机制作为"安全网"——更新出问题了，能一键回到更新前的状态。

7.1 回滚的触发条件

回滚不是只在"更新失败"时才触发，以下几种情况都应该触发回滚：

• 更新过程中文件校验不通过：下载的文件损坏，无法继续更新，回退到旧版本。
• 新版本无法启动：更新完成后，EA初始化失败（比如依赖文件缺失、配置格式不兼容），自动回滚。
• 用户主动申请回滚：用户更新后发现新版本不好用、或者新版本有Bug，要求回到旧版本。
• 运行异常检测：更新后EA出现异常行为（如频繁报错、内存泄漏），可以设置一个"观察期"，观察期内出问题自动回滚。

7.2 版本快照管理

回滚的基础是备份。每次更新之前，把当前版本的所有文件备份一份，这就是一个"版本快照"。需要回滚时，把快照里的文件恢复回去就行。

但是备份不能无限期保留，否则占用空间会越来越大。建议的策略是：保留最近3-5个版本的快照，老版本的备份自动清理。对于大多数EA产品来说，能回退到上一两个版本就足够了。

备份目录建议放在 MQL5/Files/产品名/backup/ 下，每个版本一个子文件夹，用版本号命名（如 backup/1.2.3/）。这样结构清晰，也方便管理。

7.3 自更新安装脚本实现

下面的脚本是一个完整的自更新安装脚本（SelfUpdater.mq5），涵盖了下载、校验、备份、替换、回滚等核心流程，可以作为MQL5脚本直接运行：

//+------------------------------------------------------------------+
//|                                                  SelfUpdater.mq5 |
//|                        EA自更新安装脚本（Script类型）              |
//|                        功能：下载更新包→校验→备份→替换→回滚        |
//+------------------------------------------------------------------+
#property script_show_inputs

input string UpdatePackageURL = "";  // 更新包下载地址
input string TargetVersion    = "";  // 目标版本号
input string ProductName      = "MyEA";  // 产品名称，用于路径管理

// 全局变量
string   g_data_path;         // 产品数据目录
string   g_backup_path;       // 备份目录
string   g_temp_path;         // 临时下载目录
string   g_current_version;   // 当前版本号

//+------------------------------------------------------------------+
//| 脚本入口函数                                                      |
//+------------------------------------------------------------------+
void OnStart()
{
   // 检查输入参数
   if(UpdatePackageURL == "" || TargetVersion == "")
   {
      Print("错误：请填写更新包URL和目标版本号");
      return;
   }

   // 初始化目录路径
   g_data_path   = TerminalInfoString(TERMINAL_DATA_PATH) + "\\MQL5\\Files\\" + ProductName + "\\";
   g_backup_path = g_data_path + "backup\\" + g_current_version + "\\";
   g_temp_path   = g_data_path + "temp\\";

   // 确保目录存在
   FolderCreate(g_data_path);
   FolderCreate(g_backup_path);
   FolderCreate(g_temp_path);

   Print("开始更新：", g_current_version, " → ", TargetVersion);

   // 第1步：下载更新包
   Print("第1步：正在下载更新包...");
   string package_file = g_temp_path + "update_" + TargetVersion + ".zip";

   if(!DownloadFile(UpdatePackageURL, package_file))
   {
      Print("错误：更新包下载失败");
      return;
   }

   // 第2步：校验更新包（MD5校验，实际项目中传入预期的MD5值）
   Print("第2步：校验更新包...");
   // 这里省略MD5校验代码，实际项目中需要实现
   // 如果校验失败，直接返回，不执行后续步骤

   // 第3步：备份当前版本
   Print("第3步：备份当前版本...");
   if(!BackupCurrentVersion())
   {
      Print("错误：备份失败，中止更新");
      return;
   }

   // 第4步：解压并替换文件
   Print("第4步：安装更新...");
   if(!InstallUpdate(package_file))
   {
      Print("错误：安装失败，执行回滚...");
      Rollback();
      return;
   }

   // 第5步：验证更新结果
   Print("第5步：验证更新...");
   if(!VerifyUpdate(TargetVersion))
   {
      Print("错误：验证失败，执行回滚...");
      Rollback();
      return;
   }

   // 第6步：更新完成，清理临时文件
   Print("第6步：更新完成，清理临时文件...");
   CleanupTemp();

   Print("更新成功：", g_current_version, " → ", TargetVersion);
   MessageBox("更新成功！\n新版本：" + TargetVersion + "\n\n请重启MT5使更新生效。", "更新完成", MB_OK | MB_ICONINFORMATION);
}

//+------------------------------------------------------------------+
//| 下载文件函数                                                      |
//+------------------------------------------------------------------+
bool DownloadFile(string url, string save_path)
{
   CWebRequest request;
   request.Timeout(30000);  // 30秒超时，下载文件可以长一点

   // 下载到临时文件
   if(!request.Download(url, save_path))
   {
      Print("下载失败：", request.ResultCode());
      return false;
   }

   // 检查文件是否存在且大小不为0
   if(FileSize(save_path) <= 0)
   {
      Print("下载失败：文件为空");
      FileDelete(save_path);
      return false;
   }

   return true;
}

//+------------------------------------------------------------------+
//| 备份当前版本                                                      |
//+------------------------------------------------------------------+
bool BackupCurrentVersion()
{
   // 读取本地manifest获取当前版本文件列表
   string manifest_path = g_data_path + "manifest.json";
   if(!FileExists(manifest_path))
   {
      Print("警告：未找到本地manifest，执行完整目录备份");
      // 退化为备份整个产品目录
      return CopyDirectory(g_data_path, g_backup_path);
   }

   // 读取manifest，逐个备份文件
   // 实际项目中解析manifest中的文件列表
   // 这里简化处理：备份整个Experts目录下的产品相关文件

   return true;
}

//+------------------------------------------------------------------+
//| 安装更新（解压并替换文件）                                         |
//+------------------------------------------------------------------+
bool InstallUpdate(string package_file)
{
   // 解压更新包到临时目录
   string extract_path = g_temp_path + "extract\\";
   FolderCreate(extract_path);

   // MQL5原生不支持zip解压，有两种方案：
   // 方案1：调用系统命令调用7z.exe解压
   // 方案2：使用第三方MQL5 zip库
   // 这里用方案1做演示

   string command = "7z.exe x \"" + package_file + "\" -o\"" + extract_path + "\" -y";

   // 执行系统命令（简化示例）
   // int ret = ShellExecuteW(0, "open", "cmd.exe", "/c " + command, ...);
   // 实际使用中需要等待命令执行完成并检查返回值

   // 解压完成后，将文件复制到目标位置
   // 按照manifest中的文件映射关系复制
   // 这里简化处理

   return true;
}

//+------------------------------------------------------------------+
//| 回滚到上一个版本                                                  |
//+------------------------------------------------------------------+
void Rollback()
{
   Print("正在执行回滚...");

   // 把备份目录的文件复制回原位置
   if(CopyDirectory(g_backup_path, g_data_path))
   {
      Print("回滚成功，已恢复到版本 ", g_current_version);
      MessageBox("更新失败，已回滚到旧版本。\n当前版本：" + g_current_version, "回滚完成", MB_OK | MB_ICONWARNING);
   }
   else
   {
      Print("回滚失败！请手动检查文件状态");
      MessageBox("更新失败且回滚未成功！\n请联系技术支持。", "严重错误", MB_OK | MB_ICONERROR);
   }
}

//+------------------------------------------------------------------+
//| 验证更新结果                                                      |
//+------------------------------------------------------------------+
bool VerifyUpdate(string expected_version)
{
   // 检查新的manifest是否存在
   string new_manifest = g_data_path + "manifest.json";
   if(!FileExists(new_manifest))
   {
      Print("验证失败：新manifest不存在");
      return false;
   }

   // 读取manifest中的版本号，确认是预期版本
   // 实际项目中还要校验所有文件的MD5

   return true;
}

//+------------------------------------------------------------------+
//| 清理临时文件                                                      |
//+------------------------------------------------------------------+
void CleanupTemp()
{
   // 删除临时下载目录中的文件
   // 注意：MQL5的文件操作受沙箱限制，只能操作Files目录下的内容
}

八、完整实战——搭建你的EA自动更新系统

前面七章分别讲了安装包结构、自解压安装、版本号管理、更新检测、增量更新和回滚机制。这一章我们把这些模块串起来，从零搭建一套完整的EA自动更新系统。

8.1 系统架构总览

8.2 服务端搭建

服务端的搭建非常简单，你甚至不需要专门的服务器——只要有一个能放文件、能通过HTTP访问的空间就行。虚拟主机、云存储、VPS、CDN都可以。

服务端需要的目录结构大概是这样的：

updates/
├── latest/                          # 最新版本（快捷方式或直接放文件）
│   ├── manifest.json                # 最新版本清单（更新检测用）
│   └── update_full.zip              # 最新完整更新包
├── versions/                        # 历史版本归档
│   ├── 1.0.0/
│   │   ├── manifest.json
│   │   └── update_full.zip
│   ├── 1.1.0/
│   └── 1.2.0/
├── patches/                         # 增量更新包
│   ├── 1.1.0_to_1.2.0_patch.zip
│   └── 1.2.0_to_1.3.0_patch.zip
└── release_notes/                   # 更新日志
    └── 1.3.0.md

这里的关键是 latest/manifest.json 这个文件。客户端每次检测更新都是请求这个固定URL，所以新版本发布时，只要替换这个文件就行，客户端不用改任何东西。

8.3 客户端集成步骤

把更新模块集成到已有EA中，步骤其实不多：

1. 把 CVersionManager 类和 UpdateChecker 函数加入你的EA代码（可以放在单独的include文件中）
2. 在EA中定义当前版本号常量（建议放在文件头部，方便每次发布时修改）
3. 在 OnInit 函数中调用 UpdateChecker，检测是否有新版本
4. 如果有新版本，弹框提示用户，提供下载链接或者启动自更新脚本
5. 配置服务端manifest.json的URL地址
6. 测试：改一下服务端的版本号，看EA能不能正确检测到更新

8.4 与授权系统联动

如果你已经有了授权系统（比如本站9月28日发布的《EA授权与加密系统开发实战》中介绍的方案），那么更新系统和授权系统联动起来，可以实现更完善的产品化体验。

8.5 manifest.json 完整模板

下面是一个完整的manifest.json配置文件模板，你可以直接套用：

{
  "product_name": "TrendMaster EA",
  "product_code": "trendmaster",
  "version": "1.2.0",
  "release_date": "2026-10-05",
  "min_mt5_build": 4000,
  "mandatory": false,
  "required_auth": true,
  "release_notes": [
    "新增：支持多品种同时监控",
    "优化：趋势识别算法准确率提升15%",
    "修复：特定行情下止损不触发的问题",
    "修复：周五收盘前平仓逻辑错误"
  ],
  "download": {
    "full_url": "https://cdn.eafxtech.com/updates/latest/update_full.zip",
    "full_size": 2458624,
    "full_md5": "a1b2c3d4e5f6789012345678abcdef01",
    "patch_urls": {
      "1.1.0": "https://cdn.eafxtech.com/updates/patches/1.1.0_to_1.2.0_patch.zip",
      "1.0.0": "https://cdn.eafxtech.com/updates/patches/1.0.0_to_1.2.0_patch.zip"
    }
  },
  "files": [
    {
      "path": "Experts/TrendMaster.ex5",
      "size": 524288,
      "md5": "abc123...",
      "target": "MQL5/Experts/"
    },
    {
      "path": "Indicators/TrendMaster_Indicator.ex5",
      "size": 131072,
      "md5": "def456...",
      "target": "MQL5/Indicators/"
    },
    {
      "path": "Config/default.set",
      "size": 4096,
      "md5": "ghi789...",
      "target": "MQL5/Files/TrendMaster/config/"
    },
    {
      "path": "Docs/manual.pdf",
      "size": 1048576,
      "md5": "jkl012...",
      "target": "MQL5/Files/TrendMaster/docs/"
    }
  ]
}

九、踩坑指南——那些年我们在更新系统上踩过的坑

理论设计和实际落地之间，总是隔着一堆坑。这一章我们总结一些EA更新系统中容易踩的坑，帮你提前避坑。

9.1 文件锁定坑

这个问题的解决方案有几种：

• 方案一：提示用户手动重启：下载好更新包后，提示用户"更新包已下载，请关闭MT5后运行更新脚本"。这是最安全的方案，也是大多数商业软件的做法。
• 方案二：下次启动时更新：把更新文件放在临时目录，标记"待更新"状态。下次EA启动时（OnInit阶段），先检查有没有待更新的文件，如果有就先执行更新再继续初始化。
• 方案三：使用替换工具：有一些第三方工具可以在系统重启时替换文件（利用Windows的Pending File Rename机制），但这种方式需要管理员权限，对普通用户不太友好。

9.2 权限坑

如果MT5安装在 Program Files 目录下，而用户不是管理员权限的话，写入文件可能会被UAC阻止。这也是为什么MT5默认把数据文件夹放在用户目录下的原因。

做安装包的时候，要确保所有文件都写入到数据文件夹中（也就是 AppData 下面的那个目录），不要往 Program Files 里写东西。如果确实需要写系统目录，安装包要申请管理员权限运行。

9.3 编码坑

中文路径、中文文件名有时候会导致一些奇怪的问题。比如7-Zip解压时中文文件名乱码、MQL5的文件操作函数对UTF-8路径支持不好、HTTP请求中URL编码问题等等。

建议的做法是：内部文件全部使用英文文件名和路径，有中文名称的地方通过配置或显示名称来实现，不要把中文硬编码到文件名里。

9.4 网络坑

HTTP请求可能遇到的问题非常多：超时、DNS解析失败、代理服务器、SSL证书不被信任、网络被防火墙拦截、CDN节点故障……

应对策略是：设置合理的超时时间、做好异常捕获和错误提示、提供备用下载地址（比如主站和CDN各放一份）、更新检测失败时不要影响EA的正常运行。

9.5 兼容性坑

新版本的配置文件格式如果和旧版本不兼容，用户更新后EA可能直接崩溃或者参数全部变成默认值。这个问题经常被忽略，但对用户体验影响很大。

建议的做法是：配置文件中加入版本号字段，EA加载配置时先检查版本号，如果是旧版本格式，就执行一次配置迁移逻辑，把旧格式转换成新格式，再继续运行。这样用户更新后不用重新配置参数，体验会好很多。

十、进阶方向——打造专业级EA产品交付体系

如果你已经按照前面的内容搭建了基础的安装和更新系统，恭喜你，已经超过了90%的EA开发者。但如果你想做的是一个"专业级"的EA产品，还有很多可以优化和进阶的方向。

10.1 强制更新与可选更新的策略设计

不是所有更新都需要用户马上更。不同性质的更新，应该有不同的推送策略：

• Bug修复类更新（Patch版本）：如果修复的是不影响核心功能的小Bug，可以作为可选更新，用户想更就更，不想更也没关系。
• 重要Bug修复：如果修复的是可能影响实盘安全的严重Bug（比如止损不触发、计算错误），应该标记为重要更新，强提示用户尽快更新。
• 安全相关更新：如果是授权系统漏洞、安全隐患修复，建议强制更新——不更新就不让用，避免安全风险扩大。
• 新功能版本（Minor版本）：新功能通常是可选的，用户可以选择更或者不更。
• 主版本升级（Major版本）：大版本升级通常涉及不兼容变化，应该给用户充分的选择权和准备时间，不建议强制更新。

10.2 多EA统一更新平台

如果你不止开发一款EA产品，而是有好几个EA产品在运营，那么每个产品单独维护一套更新系统就有点重复建设了。

10.3 CI/CD集成：全自动发布流水线

10.4 产品化三件套联动总结

到这里，产品化三件套的最后一块拼图——安装与更新，我们也讲完了。让我们回过头来再看一下完整的产品化全景：

这三件套联动起来，就构成了一套完整的EA产品化交付体系。从客户第一次安装你的EA，到日常使用中的授权验证，再到后续的版本更新和维护，全链路都有标准化的解决方案。

对于EA开发者来说，把这三件套搭好之后，你就可以把更多精力放在核心的策略研发上，而不是每天被安装指导、版本混乱、更新通知这些琐事消耗时间。产品化程度越高，你能服务的客户数量就越多，边际成本就越低。

最后想说的是，EA产品化是一个循序渐进的过程。你不需要一开始就把所有功能都做出来，可以先从最简单的版本号管理和更新提示做起，然后逐步加上安装包、增量更新、回滚机制，最后再考虑灰度发布和CI/CD这些进阶功能。重要的是先开始行动，然后在实践中不断迭代完善。

微信公众号
晓辉编程

视频号
晓辉说EA