升级都是基于采用安装包发布的应用。 对于绿色免安装版本（主要是指windows平台下portable版本）不适用。

Electron自带的升级框架

优点

• 包含了版本检查逻辑及回调
• 实现了下载安装升级逻辑

缺点

• 限定了发布版本的服务器（GitHub）
• 每次都是全量更新

electron-builder的升级框架

优点

• 包含了版本检查逻辑及回调
• 实现了下载安装升级逻辑
• 支持多种版本服务器，包括自搭建的“通用服务器”
• 支持alpha/beta/latest版本更新策略
• 支持灰度发布（按用户百分比）
• 支持增量更新，实现了增量更新失败时转全量更新的策略（目前只有windows版的，项目组据说计划增加mac版本的增量更新）
• 支持构建时自动发布版本到服务器
• *支持降级更新

缺点

• 版本更新检查基于package.json中的version字段值，其值只支持三段式的版本号，无法定制。具体规则见smerv

常见问题

1. [error] Cannot download differentially, fallback to full download: Error: Cannot parse blockmap xxxxxx, error：xxxxxx

说明上传服务器的blockmap文件有问题，请根据给出的错误信息做相应处理即可。大多数可能的情况是blockmap文件在解压的时候出现问题，日志内容大概是：

Cannot download differentially, fallback to full download: Error: Cannot parse blockmap "https://api.github.com/repos/VitruxPT/w-assistant/releases/assets/18470277.blockmap", error: incorrect header check, raw data:...

blockmap文件是编译生成的，所以如果上传服务器的时候没有出现文件损坏的话，那就一定是编译时的问题，可能是本地的electron-builde和electron-updater的版本太低，请确保electron-builder使用22.8.0以上， electron-updater使用4.3.4。因为之前的版本里面存在生成blockmap文件的bug，具体可查看项目的github页面。

2. 服务器返回blockmap的mime-type不对导致parse error

在服务中设置.blockmap后缀文件的mime-type：multipart/byteranges

关于绿色免安装版本的升级

其实也并不是完全不能，除了常规的自己实现一套检查逻辑之外，其实利用electron-updater的也是可以做到的：

1. 自己构造升级检查所需的latest.yml(alpha/beta 也一样，只是具体的channel值不一样)，并同对应的新版本exe文件放在服务器上
2. 在electron-updater的版本更新检查回调中提示用户升级
3. 下载完成时要求用户选择存放目录，并提醒用户运行新版本只能是使用其选择的目录下的exe文件
4. 用户选择目录后，实现将electron-updater下载的exe从升级缓存目录移动到用户选定的目录

注意

由于绿色免安装版本本身机制限制，升级只能是全量升级（更换exe文件）无法做增量更新