“技术更替不是一场革命，而是一场漫长的进化过程。”

Hello，大家好，我是 三千。

React 官方已明确建议开发者逐步淘汰 Create React App (CRA) ，转而使用 Vite 等现代框架或工具来创建新项目。

那官方为什么要这样做呢？

一、CRA 被淘汰的背景与原因

二、Vite 成为 React 官方推荐的核心优势

三、迁移至 Vite 的具体步骤 

四、其他官方推荐的 React 框架 

五、总结与建议

• 新项目：优先选择 Vite（轻量级 CSR 项目）或 Next.js（复杂全栈应用）。


• 现有 CRA 项目：逐步迁移至 Vite，或根据需求转向 Next.js/Remix 等框架。


• 学习曲线：Vite 对 React 核心概念干扰较小，适合初学者；Next.js 功能全面但学习成本较高。

React 生态正朝着  “库+框架”协同发展 的方向演进，开发者需结合项目需求选择工具链，以平衡性能、灵活性与开发效率。

结语

以上就是今天与大家分享的全部内容，你的支持是我更新的最大动力，我们下期见！

打工人肝 文章/视频 不易，期待你一键三连的鼓励 ！！！

😐 这里是【程序员三千】，💻 一个喜欢捣鼓各种编程工具新鲜玩法的啊婆主。

🏠 已入驻：抖爸爸、b站、小红书（都叫【程序员三千】）

💽 编程/AI领域优质资源推荐 👉 http://www.yuque.com/xiaosanye-o…

前言

在 JavaScript 开发者的日常中，这样的对话时常发生：

• 👨💻 新人："为什么页面突然白屏了？"


• 👨🔧 老人："异步请求没做错误处理吧？"

async/await 看似优雅的语法糖背后，隐藏着一个关键问题：错误处理策略的抉择。

在 JavaScript 中使用 async/await 时，很多人会问：“必须使用 try/catch 吗？”

其实答案并非绝对，而是取决于你如何设计错误处理策略和代码风格。

接下来，我们将探讨 async/await 的错误处理机制、使用 try/catch 的优势，以及其他可选的错误处理方法。

async/await 的基本原理

异步代码的进化史

// 回调地狱时代

fetchData(url1, (data1) => {

  process(data1, (result1) => {

    fetchData(url2, (data2) => {

      // 更多嵌套...

    })

  })

})



// Promise 时代

fetchData(url1)

  .then(process)

  .then(() => fetchData(url2))

  .catch(handleError)



// async/await 时代

async function workflow() {

  const data1 = await fetchData(url1)

  const result = await process(data1)

  return await fetchData(url2)

}

async/await 是基于 Promise 的语法糖，它使异步代码看起来更像同步代码，从而更易读、易写。一个 async 函数总是返回一个 Promise，你可以在该函数内部使用 await 来等待异步操作完成。

如果在异步操作中出现错误（例如网络请求失败），该错误会使 Promise 进入 rejected 状态。

async function fetchData() {

  const response = await fetch("https://api.example.com/data");

  const data = await response.json();

  return data;

}

使用 try/catch 捕获错误

打个比喻，就好比铁路信号系统

想象 async 函数是一列高速行驶的列车：

• await 是轨道切换器：控制代码执行流向


• 未捕获的错误如同脱轨事故：会沿着铁路网（调用栈）逆向传播


• try/catch 是智能防护系统：
  
  
  
  • 自动触发紧急制动（错误捕获）
  
  
  • 启动备用轨道（错误恢复逻辑）
  
  
  • 向调度中心发送警报（错误日志）
  
  
  
  

为了优雅地捕获 async/await 中出现的错误，通常我们会使用 try/catch 语句。这种方式可以在同一个代码块中捕获同步和异步抛出的错误，使得错误处理逻辑更集中、直观。

• 代码逻辑集中，错误处理与业务逻辑紧密结合。


• 可以捕获多个 await 操作中抛出的错误。


• 适合需要在出错时进行统一处理或恢复操作的场景。

async function fetchData() {

  try {

    const response = await fetch("https://api.example.com/data");

    if (!response.ok) {

      throw new Error(`HTTP error! status: ${response.status}`);

    }

    const data = await response.json();

    return data;

  } catch (error) {

    console.error("Error fetching data:", error);

    // 根据需要，可以在此处处理错误，或者重新抛出以便上层捕获

    throw error;

  }

}

不使用 try/catch 的替代方案

虽然 try/catch 是最直观的错误处理方式，但你也可以不在 async 函数内部使用它，而是在调用该 async 函数时捕获错误。

在 Promise 链末尾添加 .catch()

async function fetchData() {

  const response = await fetch("https://api.example.com/data");

  if (!response.ok) {

    throw new Error(`HTTP error! status: ${response.status}`);

  }

  return response.json();

}



// 调用处使用 Promise.catch 捕获错误

fetchData()

  .then(data => {

    console.log("Data:", data);

  })

  .catch(error => {

    console.error("Error fetching data:", error);

  });

这种方式将错误处理逻辑移至函数调用方，适用于以下场景：

• 当多个调用者希望以不同方式处理错误时。


• 希望让 async 函数保持简洁，将错误处理交给全局统一的错误处理器（例如在 React 应用中可以使用 Error Boundary）。

将 await 与 catch 结合

async function fetchData() {

  const response = await fetch('https://api.example.com/data').catch(error => {

    console.error('Request failed:', error);

    return null; // 返回兜底值

  });

  if (!response) return;

  // 继续处理 response...

}

全局错误监听（慎用，适合兜底）

// 浏览器端全局监听

window.addEventListener('unhandledrejection', event => {

  event.preventDefault();

  sendErrorLog({

    type: 'UNHANDLED_REJECTION',

    error: event.reason,

    stack: event.reason.stack

  });

  showErrorToast('系统异常，请联系管理员');

});



// Node.js 进程管理

process.on('unhandledRejection', (reason, promise) => {

  logger.fatal('未处理的 Promise 拒绝:', reason);

  process.exitCode = 1;

});

错误处理策略矩阵

决策树分析

graph TD

  A[需要立即处理错误?] -->|是| B[使用 try/catch]

  A -->|否| C{错误类型}

  C -->|可恢复错误| D[Promise.catch]

  C -->|致命错误| E[全局监听]

  C -->|批量操作| F[Promise.allSettled]

错误处理体系

小结

我的观点是：不强制要求，但强烈推荐

• 不强制：如果不需要处理错误，可以不使用 try/catch，但未捕获的 Promise 拒绝（unhandled rejection）会导致程序崩溃（在 Node.js 或现代浏览器中）。


• 推荐：90% 的场景下需要捕获错误，因此 try/catch 是最直接的错误处理方式。

所有我个人观点：使用 async/await 尽量使用 try/catch。好的错误处理不是消灭错误，而是让系统具备优雅降级的能力。

你的代码应该像优秀的飞行员——在遇到气流时，仍能保持平稳飞行。大家如有不同意见，还请评论区讨论，说出自己的见解。

问题描述

公司有个内部项目是用 Electron 来开发的，有个功能需要像浏览器一样加载第三方站点。

本来一切安好，但是某天打开某个站点的链接，导致 整个客户端直接变成了该站点的页面。

这一看就是该站点做了特殊的处理，经排查网页源码后，果然发现了有这么一句代码。

    if (window.top !== window.self) {

      window.top.location = window.location;

    }

翻译一下就是：如果当前窗口不是顶级窗口的话，将当前窗口设置为顶级窗口。

奇怪的是两者不是 跨域 了吗，为什么 iframe 还可以影响顶级窗口。

先说一下我当时的一些解决办法：

后续内容就是一点复盘工作。

场景复现（Web端）

一开始怀疑是客户端的问题，所以我用在纯 Web 上进行了一次对比验证。

这里我们新建两个文件：1.html 和 2.html，我们称之为 页面A 和 页面B。

然后起了两个本地服务器来模拟同源与跨域的情况。

页面A：http://127.0.0.1:5500/1.html

页面B：http://127.0.0.1:5500/2.html 和 http://localhost:3000/2.html

符合同源策略

<body>

  <h1>这是页面A</h1>

  <!-- 这是同源的情况 -->

  <iframe id="iframe" src="http://127.0.0.1:5500/2.html" />

  

  <script>

    iframe.onload = () => {

      console.log('iframe loaded..')

      console.log('子窗口路径', iframe.contentWindow.location.href)

    }

  </script>

</body>

<body>

  <h2>这是页面B</h2>



  <script>

    console.log('page2...')

    console.log(window === window.top)

    console.log('顶部窗口路径', window.top.location.href)

  </script>

</body>

我们打开控制台可以看到 页面A 和 页面B 是可以 互相访问 到对方窗口的路径。

如果这个时候在 页面B 加上文章开头提到的 代码片段，那么显然页面将会发生变化。

跨域的情况

这时候我们修改 页面A 加载 页面B 的地址，使其不符合同源策略。

理所应当的是，两个页面不能够相互访问了，这才是正常的，否则内嵌第三方页面可以互相修改，那就太不安全了。

场景复现（客户端）

既然 Web 端是符合预期的，那是不是 Electron 自己的问题呢？

我们通过 electron-vite 快速搭建了一个 React模板的electron应用，版本为：electron@22.3.27，并且在 App 中也嵌入了刚才的 页面B。

function App(): JSX.Element {

  return (

    <>

      <h1>这是Electron页面</h1>

      <iframe id="iframe" src="http://localhost:3000/2.html"/>

    </>

  )

}

export default App

对不起，干干净净的 Electron 根本不背这个锅，在它身上的表现如同 Web端 一样，也受同源策略的限制。

那么肯定是我的项目里有什么特殊的配置，通过对比主进程的代码，答案终于揭晓。

new BrowserWindow({

    ...,

    webPreferences: {

        ...,

        webSecurity: false // 就是因为它

    }

})

Electron 官方文档 里是这么描述 webSecurity 这个配置的。

webSecurity boolean (可选) - 当设置为 false, 它将禁用同源策略 (通常用来测试网站), 如果此选项不是由开发者设置的，还会把 allowRunningInsecureContent设置为 true. 默认值为 true。

也就是说，Electron本身是有一层屏障的，但当该属性设置为 false 的时候，我们的客户端将会绕过同源策略的限制，这层屏障也就消失了，因此 iframe 的行为表现得像是嵌套了同源的站点一样。

解决方案

把这个配置去掉，确实是可以解决这个问题，但考虑到可能对其他功能造成的影响，只能采取其他方案。

如文章开头提到的，用 webview 替换 iframe。

webview 是 Electron的一个自定义元素（标签），可用于在应用程序中嵌入第三方网页，它默认开启安全策略，直接实现了主应用与嵌入页面的隔离。

因为目前这个需求是仅作展示，不需要与嵌套页面进行交互以及复杂的通信，因此在一开始的开发过程中，并没有使用它，而是直接采用了 iframe。

而 iframe 也能够实现类似的效果，只需要添加一个 sandbox 属性可以解决。

MDN 中提到，sandbox 控制应用于嵌入在 <iframe> 中的内容的限制。该属性的值可以为空以应用所有限制，也可以为空格分隔的标记以解除特定的限制。

如此一来，就算是同源的，两者也不会互相干扰。

总结

这不是一个复杂的问题，发现后及时修复了，并没有造成很大的影响（还好是自己人用的平台）。

写这篇文章的主要目的是为了记录这次事件，让我意识到在平时开发过程中，把注意力过多的放在了 业务、样式、性能等这些看得见的问题上，可能很少关注甚至忽略了 安全 这一要素，以为前端框架能够防御像 XSS 这样的攻击就能安枕无忧。

谨记，永远不要相信第三方，距离产生美。

如有纰漏，欢迎在评论区指出。

前言

本文主要介绍 Electron 客户端应用的自动更新，包括全量和增量这两种方式。

全量更新： 运行新的安装包，安装目录所有资源覆盖式更新。

增量更新： 只更新修改的部分，通常是渲染进程和主进程文件。

本文并没有拿真实项目来举例子，而是起一个 新的项目 从 0 到 1 来实现自动更新。

如果已有的项目需要支持该功能，借鉴本文的主要步骤即可。

前置说明：

准备工作

脚手架搭建项目

我们通过 electron-vite 快速搭建一个基于 Vite + React + TS 的 Electron 项目。

该模板已经包括了我们需要的核心第三方库：electron-builder，electron-updater。

前者是用来打包客户端程序的，后者是用来实现自动更新的。

在项目根目录下，已经自动生成了两份配置文件：electron-builder.yml 和 dev-app-update.yml。

electron-builder.yml

该文件描述了一些 打包配置，更多信息可参考 官网。

在这些配置项中，publish 字段比较重要，因为它关系到更新源。

publish:

  provider: generic // 使用一个通用的 HTTP 服务器作为更新源。

  url: https://example.com/auto-updates // 存放安装包和描述文件的地址

provider 字段还有其他可选项，但是本文只介绍 generic 这种方式，即把安装包放在 HTTP 服务器里。

dev-app-update.yml

provider: generic

url: https://example.com/auto-updates

updaterCacheDirName: electron-update-demo-updater

其中，updaterCacheDirName 定义下载目录，也就是安装包存放的位置。全路径是C:\Users\用户名\AppData\Local\electron-update-demo-updater，不配置则在C:\Users\用户名\AppData\Local下自动创建文件夹，开发环境下为项目名，生产环境下为项目名-updater。

模拟服务器

我们直接运行 npm run build:win，在默认 dist 文件夹下就出现了打包后的一些资源。

其实更新的基本思路就是对比版本号，即对比本地版本和 线上服务器 版本是否一致，若不一致则需要更新。

因此我们在开发调试的时候，需要起一个本地服务器，来模拟真实的情况。

新建一个文件夹 mockServer，把打包后的 setup.exe 安装包和 latest.yml 文件粘贴进去，然后通过 serve 命令默认起了一个 http://localhose:3000 的本地服务器。

既然有了存放资源的本地地址，在开发调试的时候，我们更新下 dev-app-update.yml 文件的 url 字段，也就是修改为 http://localhose:3000。

注：如果需要测试打包后的更新功能，需要同步修改打包配置文件。

全量更新

与主进程文件同级，创建 update.ts 文件，之后我们的更新逻辑将在这里展开。

import { autoUpdater } from 'electron-updater' //核心库

需要注意的是，在我们开发过程中，通过 npm run dev 起来的 Electron 程序其实不能算是打包后的状态。

你会发现在调用 autoUpdater 的一些方法会提示下面的错误：

Skip checkForUpdates because application is not packed and dev update config is not forced

因此我们需要在开发环境去做一些动作，并且手动指定 updateConfigPath：

// update.ts

if (isDev) {

  Object.defineProperty(app, 'isPackaged', {

    get: () => true

  })

  autoUpdater.updateConfigPath = path.join(__dirname, '../../dev-app-update.yml')

}

核心对象 autoUpdater 有很多可以主动调用的方法，也有一些监听事件，同时还有一些属性可以设置。

这里只展示了本人项目场景所需的一些配置。

autoUpdater.autoDownload = false // 不允许自动下载更新

autoUpdater.allowDowngrade = true // 允许降级更新（应付回滚的情况）



autoUpdater.checkForUpdates()

autoUpdater.downloadUpdate()

autoUpdater.quitAndInstall()



autoUpdater.on('checking-for-update', () => {

  console.log('开始检查更新')

})

autoUpdater.on('update-available', info => {

  console.log('发现更新版本')

})

autoUpdater.on('update-not-available', info => {

  console.log('不需要全量更新', info.version)

})

autoUpdater.on('download-progress', progressInfo => {

  console.log('更新进度信息', progressInfo)

})

autoUpdater.on('update-downloaded', () => {

  console.log('更新下载完成')

})

autoUpdater.on('error', errorMessage => {

  console.log('更新时出错了', errorMessage)

})

在监听事件里，我们可以拿到下载新版本 整个生命周期 需要的一些信息。

// 新版本的版本信息（已筛选）

interface UpdateInfo {

    readonly version: string;

    releaseName?: string | null;

    releaseNotes?: string | Array<ReleaseNoteInfo> | null;

    releaseDate: string;

}



// 下载安装包的进度信息

interface ProgressInfo {

    total: number;

    delta: number;

    transferred: number;

    percent: number;

    bytesPerSecond: number;

}

在写完这些基本的方法之后，我们需要决定 检验更新 的时机，一般是在应用程序真正启动之后，即 mainWindow 创建之后。

运行项目，预期会提示 不需要全量更新，因为刚才复制到本地服务器的 latest.yml 文件里的版本信息与本地相同。修改 version 字段，重启项目，主进程就会提示有新版本需要更新了。

频繁启动应用太麻烦，除了应用初次启动时主进程主动帮我们检验更新外，还需要用户 手动触发 版本更新检测，此外，由于产品场景需要，当发现有新版本的时候，需要在 渲染进程 通知用户，包括版本更新时间和更新内容。因此我们需要加上主进程与渲染进程的 IPC通信 来实现这个功能。

其实需要的数据主进程都能够提供了，渲染进程具体的展示及交互方式就自由发挥了，这里简单展示下我做的效果。

1. 发现新版本

2. 无需更新

增量更新

为什么要这么做

其实全量更新是一种比较简单粗暴的更新方式，我没有花费太大的篇幅去介绍，基本上就是使用 autoUpdater 封装的一些方法，开发过程中更多的注意力则是放在了渲染进程的交互上。

此外，我们的更新交互用的是一种 用户感知 的方式，即更不更新是由用户自己决定的。而 静默更新 则是用户无感知，在监测到更新后不用去通知用户，而是自行在后台下载，在某个时刻执行安装的逻辑，这种方式往往是一键安装，不会弹出让用户去选择安装路径的窗口。接下去要介绍的增量更新其实是这种 用户无感知 的形式，只不过我们更新的不是整个应用程序。

由于产品迭代比较频繁，我们的业务方经常收到更新提示，意味着他们要经常手动更新应用，以便使用到最新的功能特性。众所周知，Electron 给前端开发提供了一个比较容易上手的客户端开发解决方案，但在享受 跨平台 等特性的同时，还得忍受 臃肿的安装包 。

带宽、流量在当前不是什么大问题，下载和安装的速度也挺快，但这频繁的下载覆盖一模一样的资源文件还是挺糟心的，代码改动量小时，全量更新完全没有必要。我们希望的是，开发更新了什么代码，应用程序就替换掉这部分代码就好了，这很优雅。在 我们的场景 中，这部分代码指的是 —— main、preload、renderer，并不包括 dll、第三方SDK等资源。

网上有挺多种增量更新的 解决方案，例如：

本文我们采用较普遍的 替换asar 来实现。

优化 app.asar 体积

asar是 Electron提供的一种将多个文件合并成一个文件的类 tar 风格的归档格式，不仅可以缓解Windows下路径名过长的问题， 还能够略微加快一下 require的速度, 并且可以隐藏你的源代码。（并非完全隐藏，有方法可以找出来）

Electron 应用程序启动的时候，会读取 app.asar.unpacked 目录中的内容合并到 app.asar 的目录中进行加载。在此之前我们已经打包了一份 Demo 项目，安装到本地后，我们可以根据安装路径找到 app.asar 这个文件。

例如：D:\你的安装路径\electron-update-demo\resources

在这个 Demo 项目中，脚手架生成的模板将图标剥离出来，因此出现了一个 app.asar.unpacked 文件夹。我们不难发现，app.asar 这个文件竟然有 66 MB，再回过头看我们真正的代码文件，甚至才 1 MB ！那么到底是什么原因导致的这个文件这么大呢，刚才提到了，asar 其实是一种压缩格式，因此我们只要解压看看就知道了。

npm i -g asar // 全局安装



asar e app.asar folder // 解压到folder文件夹

解压后我们不难发现，out 文件夹里的才是我们打包出来的资源，罪魁祸首竟然是 node_modules，足足有 62.3 MB。

查阅资料得知，Electron 在打包的时候，会把 dependencies 字段里的依赖也一起打包进去。而我们的渲染进程是用 React开发的，这些第三方依赖早就通过 Vite 等打包工具打到资源文件里了，根本不需要再打包一次，不然我们重新下载的 app.asar 文件还是很大的，因此需要尽可能减少体积。

优化应用程序体积 == 减少 node_modules 文件夹的大小 == 减少需要打包的依赖数量 == 减少 dependencies 中的依赖。

1. 移除 dependencies

最开始我想的是把 package.json 中的 dependencies 全都移到 devDependencies，打包后的体积果然减小了，但是在测试过程中会发现某些功能依赖包会缺失，比如 @electron/remote。因此在修改这部分代码的时候，需要特别留意，哪些依赖是需要保留下来的。

由于不想影响 package.json 的版本结构，我只是在写了一个脚本，在 npm i 之后，执行打包命令前修改 devDependencies 就好了。

2. 双 package.json 结构

这是 electron-builder 官网上看到的一种技巧，传送门， 创建 app 文件夹，再创建第二个 package.json，在该文件中配置我们应用的名称、版本、主进程入口文件等信息。这样一来，electron-builder 在打包时会以该文件夹作为打包的根文件夹，即只会打包这个文件夹下的文件。

但是我原项目的主进程和预加载脚本也放在这，尝试修改后出现打包错误的情况，感兴趣的可以试试。

这是我们优化之后的结果，1.32 MB，后面只需要替换这个文件就实现了版本的更新。

校验增量更新

全量更新的校验逻辑是第三方库已经封装好了的，那么对于增量更新，就得由我们自己来实现了。

首先明确一下 校验的时机，package.json 的 version 字段表示应用程序的版本，用于全量更新的判断，那也就意味着，当这个字段保持不变的时候，会触发上文提到的 update-not-available 事件。所以我们可以在这个事件的回调函数里来进行校验。

autoUpdater.on('update-not-available', info => { console.log('不需要全量更新', info.version) })

然后就是 如何校验，我们回过头来看 electron-builder 的打包配置，在 releaseInfo 字段里描述了发行版本的一些信息，目前我们用到了 releaseNotes 来存储更新日志，查阅官网得知还有个 releaseName 好像对于我们而言是没什么用的，那么我们就可以把它作为增量更新的 热版本号。（但其实 官网 配置项还有个 vendor 字段，可是我在用的时候打包会报错，可能是版本的问题，感兴趣的可以试试。）

每次发布新版本的时候，只要不是 Electron自身版本变化 等重大更新，我们都可以通过修改 releaseInfo 的 releaseName 来发布我们的热版本号。现在我们已经有了线上的版本，那 本地热版本号 该如何获取呢。这里我们在每次热更新完成之后，就会把最新的版本号存储在本地的一个配置文件中，通常是 userData 文件夹，用于存储我们应用程序的用户信息，即使程序卸载 了也不会影响里面的资源。在 Windows 下，路径如下：
C:\Users\用户名\AppData\Roaming\electron-update-demo。

因此，整个 校验流程 就是，在打开程序的时候，autoUpdater 触发 update-not-available 事件，拿到线上 latest.yml 描述的 releaseName 作为热版本号，与本地配置文件（我们命名为 config.json）里存储的热版本号（我们命名为 hotVersion）进行对比，若不同就去下载最新的 app.asar 文件。

我们使用 electron-log 来记录日志，代码如下所示。

// 本地配置文件

const localConfigFile = path.join(app.getPath('userData'), 'config.json')



const checkHotVersion = (latestHotVersion: string): boolean => {

  let needDownload = false

  if (!fs.existsSync(localConfigFile)) {

    fs.writeFileSync(localConfigFile, '{}', 'utf8')

    log.info('配置文件不存在，已自动创建')

  } else {

    log.info('监测到配置文件')

  }



  try {

    const configStr = fs.readFileSync(localConfigFile, 'utf8')

    const configData = JSON.parse(configStr || '{}')

    // 对比版本号

    if (latestHotVersion !== configData.hotVersion) {

      log.info('当前版本不是最新热更版本')

      needDownload = true

    } else {

      log.info('当前为最新版本')

    }

  } catch (error) {

    log.error('读取配置文件时出错', error)

  }



  return needDownload

}

下载增量更新包

通过刚才的校验，我们已经知道了什么时候该去下载增量更新包。

在开发调试的时候，我们可以把新版本的 app.asar 也放到起了本地服务器的 mockServer 文件夹里来模拟真实的情况。有很多方式可以去下载文件，这里我用了 nodejs 的 http 模块去实现，如果是 https 的需要引用 https 模块。

下载到本地的时候，我是放在了与 app.asar 同级目录的 resources 文件夹，我们不能直接覆盖原文件。一是因为进程权限占用的问题，二是为了容错，所以我们需要以另一个名字来命名下载后的文件（这里我们用的是 app.asar-temp），也就不需要去备份原文件了，代码如下。

const resourcePath = isDev

    ? path.join('D:\\测试\\electron-update-demo\\resources')

    : process.resourcesPath



const localAsarTemp = path.join(resourcePath, 'app.asar-temp')



const asarUrl = 'http://localhost:3000/app.asar'



downloadAsar() {

  const fileStream = fs.createWriteStream(localAsarTemp)

  http.get(asarUrl, res => {

    res.pipe(fileStream)

    fileStream

      .on('finish', () => {

        log.info('asar下载完成')

      })

      .on('error', error => {

        // 删除文件

        fs.unlink(localAsarTemp, () => {

          log.error('下载出现异常，已中断', error)

        })

      })

  })

}

因此，我们的流程更新为：发现新版本后，下载最新的 app.asar 到 resources 目录，并重命名为 app.asar-temp。这个时候我们启动项目进行调试，找到记录在本地的日志—— C:\Users\用户名\AppData\Roaming\electron-update-demo\logs，会有以下的记录：

[2024-09-20 13:49:22.456] [info]  监测到配置文件

[2024-09-20 13:49:22.462] [info]  当前版本不是最新热更版本

[2024-09-20 13:49:23.206] [info]  asar下载完成

在看看项目 resources 文件夹，多了一个 app.asar-temp文件。

至此，下载这一步已经完成了，但这样还会有一个问题，因为文件名没有加上版本号，也没有重复性校验，倘若一直没有更新，那么每次启动应用需要增量更新的时候都需要再次下载。

替换 app.asar 文件

好了，新文件也有了，接下来就是直接替换掉老文件就可以了，但是 替换的时机 很重要。

在 Windows 操作系统下，直接替换 app.asar 会提示程序被占用而导致失败，所以我们应该在程序关闭的时候实现替换。

我们有上面两种方案，最终采用了 方案2。

在主进程监听 app.on('quit') 事件，在应用退出的时候，判断 app.asar 和 app.asar-temp 是否同时存在，若同时存在，就去替换。这里替换不能直接用 nodejs 在主进程里去写，因为主进程执行的时候，资源还是被占用的。因此我们需要额外起一个 子进程 去做。

nodejs 可以通过 spawn、exec 等方法创建一个子进程。子进程可以执行一些自定义的命令，我们并没有使用子进程去执行 nodejs，因为业务方的机器上不一定有这个环境，而是采用了启动 exe 可执行文件的方式。可能有人问为什么不直接运行 .bat 批处理文件，因为我调试关闭应用的时候，会有一个 命令框闪烁 的现象，这不太优雅，尽管已经设置 spawn 的 windowsHide: true。

那么如何获得这个 exe 可执行文件呢，其实是通过 bat 文件去编译的，命令如下：

@echo off

timeout /T 1 /NOBREAK

del /f /q /a %1\app.asar

ren %1\app.asar-temp app.asar

我们加了延时，等待父进程完全关闭后，再去执行后续命令。其中 %1 为运行脚本传入的参数，在我们的场景里就是 resources 文件夹的地址，因为每个人的安装地址应该是不一样的，所以需要作为参数传进去。

转换文件的工具一开始用的是 Bat To Exe Converter 下载地址，但是在实际使用的过程中，我的电脑竟然把转换后的 exe 文件 识别为病毒，但在其他同事电脑上没有这种表现，这肯定就不行了，最后还是同事使用 python 帮我转换生成了一份可用的文件（replace.exe）。

这里我们可以选择不同的方式把 replace.exe 存放到 用户目录 上，要么是从线上服务器下载，要么是安装的时候就已经存放在本地了。我们选择了后者，这需要修改 electron-builder 打包配置，指定 asarUnpack, 这样就会存放在 app.asar.unpacked 文件夹中，不经常修改的文件都可以放在这里，不会随着增量更新而替换掉。

有了这个替换脚本之后，开始编写子进程相关的代码。

import { spawn } from 'child_process'



cosnt localExePath = path.join(resourcePath, 'app.asar.unpacked/resources/replace.exe')



replaceAsar() {

  if (fs.existsSync(localAsar) && fs.existsSync(localAsarTemp)) {

    const command = `${localExePath} ${resourcePath}`

    log.info(command)

    const logPath = app.getPath('logs')

    const childOut = fs.openSync(path.join(logPath, './out.log'), 'a')

    const childErr = fs.openSync(path.join(logPath, './err.log'), 'a')

    const child = spawn(`"${localExePath}"`, [`"${resourcePath}"`], {

      detached: true, // 允许子进程独立

      shell: true,

      stdio: ['ignore', childOut, childErr]

    })

    child.on('spawn', () => log.info('子进程触发'))

    child.on('error', err => log.error('child error', err))

    child.on('close', code => log.error('child close', code))

    child.on('exit', code => log.error('child exit', code))

    child.stdout?.on('data', data => log.info('stdout', data))

    child.stderr?.on('data', data => log.info('stderr', data))

    child.unref()

  }

}



app.on('quit', () => {

  replaceAsar()

})

在这块代码中，创建子进程的配置项比较重要，尤其是路径相关的。因为用户安装路径是不同的，可能会存在 文件夹名含有空格 的情况，比如 Program Files，这会导致在执行的时候将空格识别为分隔符，导致命令执行失败，因此需要加上 双引号。此外，detached: true 可以让子进程独立出来，也就是父进程退出后可以执行，而shell: true 可以将路径名作为参数传过去。

const child = spawn(`"${localExePath}"`, [`"${resourcePath}"`], {

  detached: true,

  shell: true,

  stdio: ['ignore', childOut, childErr]

})

但这块有个 疑惑，为什么我的 close、exit 以及 stdout 都没有触发，以至于不能拿到命令是否执行成功的最终结果，了解的同学可以评论区交流一下。

至此，在关闭应用之后，app.asar 就已经被替换为最新版本了，还差最后一步，更新本地配置文件里的 hotVersion，防止下次又去下载更新包了。

child.on('spawn', () => {

  log.info('子进程触发')

  updateHotVersion()

})



updateHotVersion() {

  fs.writeFileSync(localConfigFile, JSON.stringify({ hotVersion }, null, 2))

}

增量更新日志提示

既然之前提到的全量更新有日志说明，那增量更新可以不用，也应该需要具备这个能力，不然我们神不知鬼不觉帮用户更新了，用户都不知道 新在哪里。

至于更新内容，我们可以复用 releaseInfo 的 releaseNotes 字段，把更新日志写在这里，增量更新完成后展现给用户就好了。

但是总不能每次打开都展示，这里需要用户有个交互，比如点击 知道了 按钮，或者关闭 Modal 后，把当前的热更新版本号保存在本地配置文件，记录为 logVersion。在下次打开程序或者校验更新的时候，我们判断一下 logVersion === hotVersion，若不同，再去提示更新日志。

日志版本 校验和修改的代码如下所示：

checkLogVersion() {

  let needShowLog = false

  try {

    const configStr = fs.readFileSync(localConfigFile, 'utf8')

    const configData = JSON.parse(configStr || '{}')

    const { hotVersion, logVersion } = configData

    if (hotVersion !== logVersion) {

      log.info('日志版本与当前热更新版本不同，需要提示更新日志')

      needShowLog = true

    } else {

      log.info('日志已是最新版本，无需提示更新日志')

    }

  } catch (error) {

    log.error('读取配置文件失败', error)

  }

  return needShowLog

}



updateLogVersion() {

  try {

    const configStr = fs.readFileSync(localConfigFile, 'utf8')

    const configData = JSON.parse(configStr || '{}')

    const { hotVersion } = configData

    fs.writeFileSync(localConfigFile, JSON.stringify({ hotVersion, logVersion: hotVersion }, null, 2))

    log.info('日志版本已更新')

  } catch (error) {

    log.error('读取配置文件失败', error)

  }

}

读取 config.json 文件的方法自行封装一下，我这里就重复使用了。主进程 ipcMain.on 监听一下用户传递过来的事件，再去调用 updateLogVersion 即可，渲染进程效果如下：

提示增量更新日志

点击 知道了 后，再次打开应用后就不会提示日志了，因为本地配置文件已经被修改了。

当然可能也有这么个场景，开发就改了一点点无关功能的代码，无需向用户展示日志，我们只需要加一个判断 releaseNotes 是否为空的逻辑就好了，也做到了 静默更新。

小结

不足之处

本文提出的增量更新方案应该算是比较简单的，可能并不适用于所有的场景，考虑也不够全面，例如：

流程图

针对本文的解决方案，我简单画了一个 流程图。

参考文章

网上其实有不少关于 Electron 自动更新的文章，在做这个需求之前也是浏览了好多，但也有些没仔细看完，所以就躺在我的标签页没有关闭，在这罗列出来，也当作收藏了。

写这篇文章的目的也是为了记录和复盘，如果能为你提供一些思路那就再好不过了。

鸣谢：

前言

本文主要介绍 Electron 客户端应用的自动更新，包括全量和增量这两种方式。

全量更新： 运行新的安装包，安装目录所有资源覆盖式更新。

增量更新： 只更新修改的部分，通常是渲染进程和主进程文件。

本文并没有拿真实项目来举例子，而是起一个 新的项目 从 0 到 1 来实现自动更新。

如果已有的项目需要支持该功能，借鉴本文的主要步骤即可。

前置说明：

准备工作

脚手架搭建项目

我们通过 electron-vite 快速搭建一个基于 Vite + React + TS 的 Electron 项目。

该模板已经包括了我们需要的核心第三方库：electron-builder，electron-updater。

前者是用来打包客户端程序的，后者是用来实现自动更新的。

在项目根目录下，已经自动生成了两份配置文件：electron-builder.yml 和 dev-app-update.yml。

electron-builder.yml

该文件描述了一些 打包配置，更多信息可参考 官网。

在这些配置项中，publish 字段比较重要，因为它关系到更新源。

publish:

  provider: generic // 使用一个通用的 HTTP 服务器作为更新源。

  url: https://example.com/auto-updates // 存放安装包和描述文件的地址

provider 字段还有其他可选项，但是本文只介绍 generic 这种方式，即把安装包放在 HTTP 服务器里。

dev-app-update.yml

provider: generic

url: https://example.com/auto-updates

updaterCacheDirName: electron-update-demo-updater

其中，updaterCacheDirName 定义下载目录，也就是安装包存放的位置。全路径是C:\Users\用户名\AppData\Local\electron-update-demo-updater，不配置则在C:\Users\用户名\AppData\Local下自动创建文件夹，开发环境下为项目名，生产环境下为项目名-updater。

模拟服务器

我们直接运行 npm run build:win，在默认 dist 文件夹下就出现了打包后的一些资源。

其实更新的基本思路就是对比版本号，即对比本地版本和 线上服务器 版本是否一致，若不一致则需要更新。

因此我们在开发调试的时候，需要起一个本地服务器，来模拟真实的情况。

新建一个文件夹 mockServer，把打包后的 setup.exe 安装包和 latest.yml 文件粘贴进去，然后通过 serve 命令默认起了一个 http://localhose:3000 的本地服务器。

既然有了存放资源的本地地址，在开发调试的时候，我们更新下 dev-app-update.yml 文件的 url 字段，也就是修改为 http://localhose:3000。

注：如果需要测试打包后的更新功能，需要同步修改打包配置文件。

全量更新

与主进程文件同级，创建 update.ts 文件，之后我们的更新逻辑将在这里展开。

import { autoUpdater } from 'electron-updater' //核心库

需要注意的是，在我们开发过程中，通过 npm run dev 起来的 Electron 程序其实不能算是打包后的状态。

你会发现在调用 autoUpdater 的一些方法会提示下面的错误：

Skip checkForUpdates because application is not packed and dev update config is not forced

因此我们需要在开发环境去做一些动作，并且手动指定 updateConfigPath：

// update.ts

if (isDev) {

  Object.defineProperty(app, 'isPackaged', {

    get: () => true

  })

  autoUpdater.updateConfigPath = path.join(__dirname, '../../dev-app-update.yml')

}

核心对象 autoUpdater 有很多可以主动调用的方法，也有一些监听事件，同时还有一些属性可以设置。

这里只展示了本人项目场景所需的一些配置。

autoUpdater.autoDownload = false // 不允许自动下载更新

autoUpdater.allowDowngrade = true // 允许降级更新（应付回滚的情况）



autoUpdater.checkForUpdates()

autoUpdater.downloadUpdate()

autoUpdater.quitAndInstall()



autoUpdater.on('checking-for-update', () => {

  console.log('开始检查更新')

})

autoUpdater.on('update-available', info => {

  console.log('发现更新版本')

})

autoUpdater.on('update-not-available', info => {

  console.log('不需要全量更新', info.version)

})

autoUpdater.on('download-progress', progressInfo => {

  console.log('更新进度信息', progressInfo)

})

autoUpdater.on('update-downloaded', () => {

  console.log('更新下载完成')

})

autoUpdater.on('error', errorMessage => {

  console.log('更新时出错了', errorMessage)

})

在监听事件里，我们可以拿到下载新版本 整个生命周期 需要的一些信息。

// 新版本的版本信息（已筛选）

interface UpdateInfo {

    readonly version: string;

    releaseName?: string | null;

    releaseNotes?: string | Array<ReleaseNoteInfo> | null;

    releaseDate: string;

}



// 下载安装包的进度信息

interface ProgressInfo {

    total: number;

    delta: number;

    transferred: number;

    percent: number;

    bytesPerSecond: number;

}

在写完这些基本的方法之后，我们需要决定 检验更新 的时机，一般是在应用程序真正启动之后，即 mainWindow 创建之后。

运行项目，预期会提示 不需要全量更新，因为刚才复制到本地服务器的 latest.yml 文件里的版本信息与本地相同。修改 version 字段，重启项目，主进程就会提示有新版本需要更新了。

频繁启动应用太麻烦，除了应用初次启动时主进程主动帮我们检验更新外，还需要用户 手动触发 版本更新检测，此外，由于产品场景需要，当发现有新版本的时候，需要在 渲染进程 通知用户，包括版本更新时间和更新内容。因此我们需要加上主进程与渲染进程的 IPC通信 来实现这个功能。

其实需要的数据主进程都能够提供了，渲染进程具体的展示及交互方式就自由发挥了，这里简单展示下我做的效果。

1. 发现新版本

2. 无需更新

增量更新

为什么要这么做

其实全量更新是一种比较简单粗暴的更新方式，我没有花费太大的篇幅去介绍，基本上就是使用 autoUpdater 封装的一些方法，开发过程中更多的注意力则是放在了渲染进程的交互上。

此外，我们的更新交互用的是一种 用户感知 的方式，即更不更新是由用户自己决定的。而 静默更新 则是用户无感知，在监测到更新后不用去通知用户，而是自行在后台下载，在某个时刻执行安装的逻辑，这种方式往往是一键安装，不会弹出让用户去选择安装路径的窗口。接下去要介绍的增量更新其实是这种 用户无感知 的形式，只不过我们更新的不是整个应用程序。

由于产品迭代比较频繁，我们的业务方经常收到更新提示，意味着他们要经常手动更新应用，以便使用到最新的功能特性。众所周知，Electron 给前端开发提供了一个比较容易上手的客户端开发解决方案，但在享受 跨平台 等特性的同时，还得忍受 臃肿的安装包 。

带宽、流量在当前不是什么大问题，下载和安装的速度也挺快，但这频繁的下载覆盖一模一样的资源文件还是挺糟心的，代码改动量小时，全量更新完全没有必要。我们希望的是，开发更新了什么代码，应用程序就替换掉这部分代码就好了，这很优雅。在 我们的场景 中，这部分代码指的是 —— main、preload、renderer，并不包括 dll、第三方SDK等资源。

网上有挺多种增量更新的 解决方案，例如：

本文我们采用较普遍的 替换asar 来实现。

优化 app.asar 体积

asar是 Electron提供的一种将多个文件合并成一个文件的类 tar 风格的归档格式，不仅可以缓解Windows下路径名过长的问题， 还能够略微加快一下 require的速度, 并且可以隐藏你的源代码。（并非完全隐藏，有方法可以找出来）

Electron 应用程序启动的时候，会读取 app.asar.unpacked 目录中的内容合并到 app.asar 的目录中进行加载。在此之前我们已经打包了一份 Demo 项目，安装到本地后，我们可以根据安装路径找到 app.asar 这个文件。

例如：D:\你的安装路径\electron-update-demo\resources

在这个 Demo 项目中，脚手架生成的模板将图标剥离出来，因此出现了一个 app.asar.unpacked 文件夹。我们不难发现，app.asar 这个文件竟然有 66 MB，再回过头看我们真正的代码文件，甚至才 1 MB ！那么到底是什么原因导致的这个文件这么大呢，刚才提到了，asar 其实是一种压缩格式，因此我们只要解压看看就知道了。

npm i -g asar // 全局安装



asar e app.asar folder // 解压到folder文件夹

解压后我们不难发现，out 文件夹里的才是我们打包出来的资源，罪魁祸首竟然是 node_modules，足足有 62.3 MB。

查阅资料得知，Electron 在打包的时候，会把 dependencies 字段里的依赖也一起打包进去。而我们的渲染进程是用 React开发的，这些第三方依赖早就通过 Vite 等打包工具打到资源文件里了，根本不需要再打包一次，不然我们重新下载的 app.asar 文件还是很大的，因此需要尽可能减少体积。

优化应用程序体积 == 减少 node_modules 文件夹的大小 == 减少需要打包的依赖数量 == 减少 dependencies 中的依赖。

1. 移除 dependencies

最开始我想的是把 package.json 中的 dependencies 全都移到 devDependencies，打包后的体积果然减小了，但是在测试过程中会发现某些功能依赖包会缺失，比如 @electron/remote。因此在修改这部分代码的时候，需要特别留意，哪些依赖是需要保留下来的。

由于不想影响 package.json 的版本结构，我只是在写了一个脚本，在 npm i 之后，执行打包命令前修改 devDependencies 就好了。

2. 双 package.json 结构

这是 electron-builder 官网上看到的一种技巧，传送门， 创建 app 文件夹，再创建第二个 package.json，在该文件中配置我们应用的名称、版本、主进程入口文件等信息。这样一来，electron-builder 在打包时会以该文件夹作为打包的根文件夹，即只会打包这个文件夹下的文件。

但是我原项目的主进程和预加载脚本也放在这，尝试修改后出现打包错误的情况，感兴趣的可以试试。

这是我们优化之后的结果，1.32 MB，后面只需要替换这个文件就实现了版本的更新。

校验增量更新

全量更新的校验逻辑是第三方库已经封装好了的，那么对于增量更新，就得由我们自己来实现了。

首先明确一下 校验的时机，package.json 的 version 字段表示应用程序的版本，用于全量更新的判断，那也就意味着，当这个字段保持不变的时候，会触发上文提到的 update-not-available 事件。所以我们可以在这个事件的回调函数里来进行校验。

autoUpdater.on('update-not-available', info => { console.log('不需要全量更新', info.version) })

然后就是 如何校验，我们回过头来看 electron-builder 的打包配置，在 releaseInfo 字段里描述了发行版本的一些信息，目前我们用到了 releaseNotes 来存储更新日志，查阅官网得知还有个 releaseName 好像对于我们而言是没什么用的，那么我们就可以把它作为增量更新的 热版本号。（但其实 官网 配置项还有个 vendor 字段，可是我在用的时候打包会报错，可能是版本的问题，感兴趣的可以试试。）

每次发布新版本的时候，只要不是 Electron自身版本变化 等重大更新，我们都可以通过修改 releaseInfo 的 releaseName 来发布我们的热版本号。现在我们已经有了线上的版本，那 本地热版本号 该如何获取呢。这里我们在每次热更新完成之后，就会把最新的版本号存储在本地的一个配置文件中，通常是 userData 文件夹，用于存储我们应用程序的用户信息，即使程序卸载 了也不会影响里面的资源。在 Windows 下，路径如下：
C:\Users\用户名\AppData\Roaming\electron-update-demo。

因此，整个 校验流程 就是，在打开程序的时候，autoUpdater 触发 update-not-available 事件，拿到线上 latest.yml 描述的 releaseName 作为热版本号，与本地配置文件（我们命名为 config.json）里存储的热版本号（我们命名为 hotVersion）进行对比，若不同就去下载最新的 app.asar 文件。

我们使用 electron-log 来记录日志，代码如下所示。

// 本地配置文件

const localConfigFile = path.join(app.getPath('userData'), 'config.json')



const checkHotVersion = (latestHotVersion: string): boolean => {

  let needDownload = false

  if (!fs.existsSync(localConfigFile)) {

    fs.writeFileSync(localConfigFile, '{}', 'utf8')

    log.info('配置文件不存在，已自动创建')

  } else {

    log.info('监测到配置文件')

  }



  try {

    const configStr = fs.readFileSync(localConfigFile, 'utf8')

    const configData = JSON.parse(configStr || '{}')

    // 对比版本号

    if (latestHotVersion !== configData.hotVersion) {

      log.info('当前版本不是最新热更版本')

      needDownload = true

    } else {

      log.info('当前为最新版本')

    }

  } catch (error) {

    log.error('读取配置文件时出错', error)

  }



  return needDownload

}

下载增量更新包

通过刚才的校验，我们已经知道了什么时候该去下载增量更新包。

在开发调试的时候，我们可以把新版本的 app.asar 也放到起了本地服务器的 mockServer 文件夹里来模拟真实的情况。有很多方式可以去下载文件，这里我用了 nodejs 的 http 模块去实现，如果是 https 的需要引用 https 模块。

下载到本地的时候，我是放在了与 app.asar 同级目录的 resources 文件夹，我们不能直接覆盖原文件。一是因为进程权限占用的问题，二是为了容错，所以我们需要以另一个名字来命名下载后的文件（这里我们用的是 app.asar-temp），也就不需要去备份原文件了，代码如下。

const resourcePath = isDev

    ? path.join('D:\\测试\\electron-update-demo\\resources')

    : process.resourcesPath



const localAsarTemp = path.join(resourcePath, 'app.asar-temp')



const asarUrl = 'http://localhost:3000/app.asar'



downloadAsar() {

  const fileStream = fs.createWriteStream(localAsarTemp)

  http.get(asarUrl, res => {

    res.pipe(fileStream)

    fileStream

      .on('finish', () => {

        log.info('asar下载完成')

      })

      .on('error', error => {

        // 删除文件

        fs.unlink(localAsarTemp, () => {

          log.error('下载出现异常，已中断', error)

        })

      })

  })

}

因此，我们的流程更新为：发现新版本后，下载最新的 app.asar 到 resources 目录，并重命名为 app.asar-temp。这个时候我们启动项目进行调试，找到记录在本地的日志—— C:\Users\用户名\AppData\Roaming\electron-update-demo\logs，会有以下的记录：

[2024-09-20 13:49:22.456] [info]  监测到配置文件

[2024-09-20 13:49:22.462] [info]  当前版本不是最新热更版本

[2024-09-20 13:49:23.206] [info]  asar下载完成

在看看项目 resources 文件夹，多了一个 app.asar-temp文件。

至此，下载这一步已经完成了，但这样还会有一个问题，因为文件名没有加上版本号，也没有重复性校验，倘若一直没有更新，那么每次启动应用需要增量更新的时候都需要再次下载。

替换 app.asar 文件

好了，新文件也有了，接下来就是直接替换掉老文件就可以了，但是 替换的时机 很重要。

在 Windows 操作系统下，直接替换 app.asar 会提示程序被占用而导致失败，所以我们应该在程序关闭的时候实现替换。

我们有上面两种方案，最终采用了 方案2。

在主进程监听 app.on('quit') 事件，在应用退出的时候，判断 app.asar 和 app.asar-temp 是否同时存在，若同时存在，就去替换。这里替换不能直接用 nodejs 在主进程里去写，因为主进程执行的时候，资源还是被占用的。因此我们需要额外起一个 子进程 去做。

nodejs 可以通过 spawn、exec 等方法创建一个子进程。子进程可以执行一些自定义的命令，我们并没有使用子进程去执行 nodejs，因为业务方的机器上不一定有这个环境，而是采用了启动 exe 可执行文件的方式。可能有人问为什么不直接运行 .bat 批处理文件，因为我调试关闭应用的时候，会有一个 命令框闪烁 的现象，这不太优雅，尽管已经设置 spawn 的 windowsHide: true。

那么如何获得这个 exe 可执行文件呢，其实是通过 bat 文件去编译的，命令如下：

@echo off

timeout /T 1 /NOBREAK

del /f /q /a %1\app.asar

ren %1\app.asar-temp app.asar

我们加了延时，等待父进程完全关闭后，再去执行后续命令。其中 %1 为运行脚本传入的参数，在我们的场景里就是 resources 文件夹的地址，因为每个人的安装地址应该是不一样的，所以需要作为参数传进去。

转换文件的工具一开始用的是 Bat To Exe Converter 下载地址，但是在实际使用的过程中，我的电脑竟然把转换后的 exe 文件 识别为病毒，但在其他同事电脑上没有这种表现，这肯定就不行了，最后还是同事使用 python 帮我转换生成了一份可用的文件（replace.exe）。

这里我们可以选择不同的方式把 replace.exe 存放到 用户目录 上，要么是从线上服务器下载，要么是安装的时候就已经存放在本地了。我们选择了后者，这需要修改 electron-builder 打包配置，指定 asarUnpack, 这样就会存放在 app.asar.unpacked 文件夹中，不经常修改的文件都可以放在这里，不会随着增量更新而替换掉。

有了这个替换脚本之后，开始编写子进程相关的代码。

import { spawn } from 'child_process'



cosnt localExePath = path.join(resourcePath, 'app.asar.unpacked/resources/replace.exe')



replaceAsar() {

  if (fs.existsSync(localAsar) && fs.existsSync(localAsarTemp)) {

    const command = `${localExePath} ${resourcePath}`

    log.info(command)

    const logPath = app.getPath('logs')

    const childOut = fs.openSync(path.join(logPath, './out.log'), 'a')

    const childErr = fs.openSync(path.join(logPath, './err.log'), 'a')

    const child = spawn(`"${localExePath}"`, [`"${resourcePath}"`], {

      detached: true, // 允许子进程独立

      shell: true,

      stdio: ['ignore', childOut, childErr]

    })

    child.on('spawn', () => log.info('子进程触发'))

    child.on('error', err => log.error('child error', err))

    child.on('close', code => log.error('child close', code))

    child.on('exit', code => log.error('child exit', code))

    child.stdout?.on('data', data => log.info('stdout', data))

    child.stderr?.on('data', data => log.info('stderr', data))

    child.unref()

  }

}



app.on('quit', () => {

  replaceAsar()

})

在这块代码中，创建子进程的配置项比较重要，尤其是路径相关的。因为用户安装路径是不同的，可能会存在 文件夹名含有空格 的情况，比如 Program Files，这会导致在执行的时候将空格识别为分隔符，导致命令执行失败，因此需要加上 双引号。此外，detached: true 可以让子进程独立出来，也就是父进程退出后可以执行，而shell: true 可以将路径名作为参数传过去。

const child = spawn(`"${localExePath}"`, [`"${resourcePath}"`], {

  detached: true,

  shell: true,

  stdio: ['ignore', childOut, childErr]

})

但这块有个 疑惑，为什么我的 close、exit 以及 stdout 都没有触发，以至于不能拿到命令是否执行成功的最终结果，了解的同学可以评论区交流一下。

至此，在关闭应用之后，app.asar 就已经被替换为最新版本了，还差最后一步，更新本地配置文件里的 hotVersion，防止下次又去下载更新包了。

child.on('spawn', () => {

  log.info('子进程触发')

  updateHotVersion()

})



updateHotVersion() {

  fs.writeFileSync(localConfigFile, JSON.stringify({ hotVersion }, null, 2))

}

增量更新日志提示

既然之前提到的全量更新有日志说明，那增量更新可以不用，也应该需要具备这个能力，不然我们神不知鬼不觉帮用户更新了，用户都不知道 新在哪里。

至于更新内容，我们可以复用 releaseInfo 的 releaseNotes 字段，把更新日志写在这里，增量更新完成后展现给用户就好了。

但是总不能每次打开都展示，这里需要用户有个交互，比如点击 知道了 按钮，或者关闭 Modal 后，把当前的热更新版本号保存在本地配置文件，记录为 logVersion。在下次打开程序或者校验更新的时候，我们判断一下 logVersion === hotVersion，若不同，再去提示更新日志。

日志版本 校验和修改的代码如下所示：

checkLogVersion() {

  let needShowLog = false

  try {

    const configStr = fs.readFileSync(localConfigFile, 'utf8')

    const configData = JSON.parse(configStr || '{}')

    const { hotVersion, logVersion } = configData

    if (hotVersion !== logVersion) {

      log.info('日志版本与当前热更新版本不同，需要提示更新日志')

      needShowLog = true

    } else {

      log.info('日志已是最新版本，无需提示更新日志')

    }

  } catch (error) {

    log.error('读取配置文件失败', error)

  }

  return needShowLog

}



updateLogVersion() {

  try {

    const configStr = fs.readFileSync(localConfigFile, 'utf8')

    const configData = JSON.parse(configStr || '{}')

    const { hotVersion } = configData

    fs.writeFileSync(localConfigFile, JSON.stringify({ hotVersion, logVersion: hotVersion }, null, 2))

    log.info('日志版本已更新')

  } catch (error) {

    log.error('读取配置文件失败', error)

  }

}

读取 config.json 文件的方法自行封装一下，我这里就重复使用了。主进程 ipcMain.on 监听一下用户传递过来的事件，再去调用 updateLogVersion 即可，渲染进程效果如下：

提示增量更新日志

点击 知道了 后，再次打开应用后就不会提示日志了，因为本地配置文件已经被修改了。

当然可能也有这么个场景，开发就改了一点点无关功能的代码，无需向用户展示日志，我们只需要加一个判断 releaseNotes 是否为空的逻辑就好了，也做到了 静默更新。

小结

不足之处

本文提出的增量更新方案应该算是比较简单的，可能并不适用于所有的场景，考虑也不够全面，例如：

流程图

针对本文的解决方案，我简单画了一个 流程图。

参考文章

网上其实有不少关于 Electron 自动更新的文章，在做这个需求之前也是浏览了好多，但也有些没仔细看完，所以就躺在我的标签页没有关闭，在这罗列出来，也当作收藏了。

写这篇文章的目的也是为了记录和复盘，如果能为你提供一些思路那就再好不过了。

鸣谢：

从“跑路程序员”到“摸鱼仙人”，我用这插件把国际化的屎山代码盘活了！

tips：使用有道翻译，朋友们，要去有道官网注册一下，有免费额度，github demo的key已经被用完了。

一、命运的齿轮开始转动

“小王啊，海外业务要上线了，国际化你搞一下，下个月验收。”组长轻描淡写的一句话，让我盯着祖传代码陷入沉思——

（脑补画面：满屏中文硬编码，夹杂着"确定"、"取消"、"加载中..."）

正当我准备打开BOSS直聘时，GitHub Trending上一个项目突然闪现——

auto-i18n-translation-plugins

项目简介赫然写着：“不改代码，三天交付国际化需求，摸鱼率提升300%”

二、极限操作：48小时从0到8国语言

🔧 第1步：安装插件（耗时5分钟）

祖训：“工欲善其事，必先装依赖”

# 如果你是Vite玩家（比如Vue3项目）

npm install vite-auto-i18n-plugin --save-dev



# 如果你是Webpack钉子户（比如React老项目）

npm install webpack-auto-i18n-plugin --save-dev

🔧 第2步：配置插件（关键の10分钟）

Vue3 + Vite の 摸鱼配置：

// vite.config.js

import { defineConfig } from 'vite';

import vitePluginAutoI18n from 'vite-auto-i18n-plugin';



export default defineConfig({

  plugins: [

    vue(),

    vitePluginAutoI18n({

        targetLangList: ['en', 'ja', 'ko'],  // 要卷就卷8国语言！

        translator: new YoudaoTranslator({   // 用有道！不用翻墙！

          appId: '你的白嫖ID',      // 去官网申请，10秒搞定

          appKey: '你的密钥'       // 别用示例里的，会炸！

        })

    })

  ]

});

🔧 第3步：注入灵魂——配置文件（生死攸关の5分钟）

在项目入口文件（如main.js）的第一行插入：

// 这是插件的生命线！必须放在最前面！

import '../lang/index.js';  // 运行插件之后会自动生成引入即可

三、见证奇迹的时刻

🚀 第一次运行（心脏骤停の瞬间）

输入npm run dev，控制台开始疯狂输出：

[插件日志] 检测到中文文本："登录" → 生成哈希键：a1b2c3  

[插件日志] 调用有道翻译："登录" → 英文：Login，日文：ログイン...  

[插件日志] 生成文件：lang/index.json（翻译の圣杯）  

突然！页面白屏了！

别慌！这是插件在首次翻译时需要生成文件，解决方法：

四、效果爆炸：我成了全组の神

1. 不可置信の48小时

当我打开浏览器那一刻——\

我（瞳孔地震）：“卧槽…真成了？！”

组长（凑近屏幕）：“这…这是你一个人做的？！”（眼神逐渐迷茫）

产品经理（掏出手机拍照）：“快！发朋友圈！《我司技术力碾压硅谷！》”

2. 插件の超能力

• 构建阶段：自动扫描所有中文 → 生成哈希键 → 调用API翻译


• 运行时：根据用户语言动态加载对应翻译


• 维护期：改个JSON文件就能更新所有语言版本

副作用：

• 测试妹子开始怀疑人生：“为什么一个bug都找不到？”


• 后端同事偷偷打听：“你这插件…能翻译Java注释吗？”

五、职场生存指南：如何优雅甩锅

🔨 场景1：测试妹子提着40米大刀来了！

问题：俄语翻译把“注册”译成“Регистрация”（原意是“登记处”）

传统应对：

• 熬夜改代码 → 重新打包 → 提交测试 → 被骂效率低
  
  插件玩家：

🔨 场景2：产品经理临时加语言

需求：“老板说下周要加印地语！”

传统灾难：

• 重新配框架 → 人肉翻译 → 测试 → 加班到秃头
  
  插件玩家：

🔨 场景3：组长怀疑你摸鱼

质问：“小王啊，你这效率…是不是有什么黑科技？”

标准话术：

“组长，这都是因为：

六、高级摸鱼の奥义

🎯 秘籍1：把翻译文件变成团队武器

（脑补画面：产品经理在Excel里疯狂改翻译，程序员在刷剧）

🎯 秘籍2：动态加载の神操作

痛点：所有语言打包进主文件 → 体积爆炸！

解决方案：

// 在index.js里搞点骚操作

const loadLanguage = async (lang) => {

  const data = await import(`../../lang/${lang}.json`); // 动态加载翻译文件

  window.$t.locale(data, 'lang'); 

};



// 切换语言时调用

loadLanguage('ja'); // 瞬间切换日语，深藏功与名

🎯 秘籍3：伪装成AI大神

七、终局：摸鱼の神，降临！

当组长在庆功会上宣布“国际化项目提前两周完成”时，我正用手机刷着《庆余年2》。

测试妹子：“你怎么一点都不激动？”

我（收起手机）：“常规操作，要习惯。”（心想：插件干活，我躺平，这才叫真正的敏捷开发！）

立即行动（打工人自救指南）：

终极警告：

⚠️ 过度使用此插件可能导致——

• 你的摸鱼时间超过工作时间，引发HR关注


• 产品经理产生“国际化需求可以随便加”的幻觉


• 老板误以为你是隐藏的技术大佬（谨慎处理！）

文末暴击：

“自从用了这插件，我司翻译团队的工作量从3周变成了3分钟——现在他们主要工作是帮我选中午吃啥。” —— 匿名用户の真实反馈

常见问题汇总

常见问题汇总

轨迹绘画

简介

• 轨迹绘画常用于展示车辆历史轨迹，运动历史记录等，本次案例采用的是汽车案例同时利用腾讯地图API，来实现地图轨迹绘画功能，具体情况根据实际项目变更。

本例是汽车轨迹绘画功能

1.在页面的onReady生命周期中创建map对象

onReady() {

        // 创建map对象

        this.map = uni.createMapContext('map');

        // 获取屏幕高度（此处获取屏幕高度是因为本示例中使用了colorui的cu-custom自定义头部，需根据系统高度来自适应）

        uni.getSystemInfo({

                success: res => {

                        this.windowHeight = res.windowHeight;

                }

        });

},

2.设置轨迹动画事件

页面代码：

<view class="container">

        <map id='map' :latitude="latitude" :longitude="longitude" :markers="covers"

                :style="{ width: '100%', height: mapHeight + 'px' }" :scale="13" :polyline="polyline">

        </map>



        <view class="btnBox">

                <button :disabled="isDisabled" @click="start" class="cu-btn bg-blue round shadow lg">开始回放</button>

                <button @click="pause" class="cu-btn bg-red round shadow lg">暂停</button>

        </view>

</view>

逻辑代码：

• 1.轨迹动画的开始事件

start() {

        if (this.movementInterval) {

                clearInterval(this.movementInterval);

        }

        this.isStart = true;

        this.moveMarker();

},

• 2.轨迹动画的暂停事件

pause() {

        this.isStart = false;

        this.isDisabled = false;

        if (this.movementInterval) {

                clearInterval(this.movementInterval);

                this.movementInterval = null;

        }

},

• 3.轨迹动画移动事件

moveMarker() {

        if (!this.isStart) return;



        if (this.playIndex >= this.coordinate.length) {

                this.playIndex = 0;

                uni.showToast({

                        title: "播放完成",

                        duration: 1400,

                        icon: "none",

                });

                this.isStart = false;

                this.isDisabled = false;

                return;

        }



        let datai = this.coordinate[this.playIndex];

        this.map.translateMarker({

                markerId: 1,

                autoRotate: true,

                destination: {

                        longitude: datai.longitude,

                        latitude: datai.latitude,

                },

                duration: 700,

                complete: () => {

                        this.playIndex++;

                        this.moveMarker();

                },

        });

},

完整代码如下

<!-- 地图轨迹组件 -->

<template>

	<view>

		<cu-custom class="navBox" bgColor="bg-gradual-blue" :isBack="true">

			<block slot="backText">返回</block>

			<block slot="content">地图轨迹</block>

		</cu-custom>



		<view class="container">

			<map id='map' :latitude="latitude" :longitude="longitude" :markers="covers"

				:style="{ width: '100%', height: mapHeight + 'px' }" :scale="13" :polyline="polyline">

			</map>



			<view class="btnBox">

				<button :disabled="isDisabled" @click="start" class="cu-btn bg-blue round shadow lg">开始回放</button>

				<button @click="pause" class="cu-btn bg-red round shadow lg">暂停</button>

			</view>

		</view>

	</view>

</template>



<script>

	export default {

		data() {

			return {

				map: null,

				movementInterval: null, // 用于存储定时器的引用

				windowHeight: 0,

				mapHeight: 0,

				timer: null,



				isDisabled: false,

				isStart: false,

				playIndex: 1,



				id: 0, // 使用 marker点击事件 需要填写id

				title: 'map',

				latitude: 34.263734,

				longitude: 108.934843,

				// 标记点

				covers: [{

					id: 1,

					width: 42,

					height: 47,

					rotate: 270,

					latitude: 34.259428,

					longitude: 108.947040,

					iconPath: 'http://zgonline.top/car.png',

					callout: {

						content: "鄂A·88888", // <img src="车牌信息" alt="" width="50%" />

						display: "ALWAYS",

						fontWeight: "bold",

						color: "#5A7BEE", //文本颜色

						fontSize: "12px",

						bgColor: "#ffffff", //背景色

						padding: 5, //文本边缘留白

						textAlign: "center",

					},

					anchor: {

						x: 0.5,

						y: 0.5,

					},

				}],



				// 线

				polyline: [],



				// 坐标数据

				coordinate: [{

						latitude: 34.259428,

						longitude: 108.947040,

						problem: false,

					},

					{

						latitude: 34.252918,

						longitude: 108.946963,

						problem: false,

					},

					{

						latitude: 34.252408,

						longitude: 108.946240,

						problem: false,

					},

					{

						latitude: 34.249286,

						longitude: 108.946184,

						problem: false,

					},

					{

						latitude: 34.248670,

						longitude: 108.946640,

						problem: false,

					},

					{

						latitude: 34.248129,

						longitude: 108.946826,

						problem: false,

					},

					{

						latitude: 34.243537,

						longitude: 108.946816,

						problem: true,

					},

					{

						latitude: 34.243478,

						longitude: 108.939003,

						problem: true,

					},

					{

						latitude: 34.241218,

						longitude: 108.939027,

						problem: true,

					},

					{

						latitude: 34.241192,

						longitude: 108.934802,

						problem: true,

					},

					{

						latitude: 34.241182,

						longitude: 108.932235,

						problem: true,

					},

					{

						latitude: 34.247227,

						longitude: 108.932311,

						problem: true,

					},

					{

						latitude: 34.250833,

						longitude: 108.932352,

						problem: true,

					},

					{

						latitude: 34.250877,

						longitude: 108.931756,

						problem: true,

					},

					{

						latitude: 34.250944,

						longitude: 108.931576,

						problem: true,

					},

					{

						latitude: 34.250834,

						longitude: 108.929662,

						problem: true,

					},

					{

						latitude: 34.250924,

						longitude: 108.926015,

						problem: true,

					},

					{

						latitude: 34.250802,

						longitude: 108.910121,

						problem: true,

					},

					{

						latitude: 34.269718,

						longitude: 108.909921,

						problem: true,

					},

					{

						latitude: 34.269221,

						longitude: 108.922366,

						problem: false,

					},

					{

						latitude: 34.274531,

						longitude: 108.922388,

						problem: false,

					},

					{

						latitude: 34.276201,

						longitude: 108.923433,

						problem: false,

					},

					{

						latitude: 34.276559,

						longitude: 108.924004,

						problem: false,

					},

					{

						latitude: 34.276785,

						longitude: 108.945855,

						problem: false,

					}

				],

				posi: {

					id: 1,

					width: 32,

					height: 32,

					latitude: 0,

					longitude: 0,

					iconPath: "http://cdn.zhoukaiwen.com/car.png",

					callout: {

						content: "鄂A·888888", // 车牌信息

						display: "BYCLICK",

						fontWeight: "bold",

						color: "#5A7BEE", //文本颜色

						fontSize: "12px",

						bgColor: "#ffffff", //背景色

						padding: 5, //文本边缘留白

						textAlign: "center",

					},

					anchor: {

						x: 0.5,

						y: 0.5,

					},

				}

			}

		},

		watch: {},

		// 分享小程序

		onShareAppMessage(res) {

			return {

				title: '看看这个小程序多好玩～',

			};

		},

		onReady() {

			// 创建map对象

			this.map = uni.createMapContext('map');

			// 获取屏幕高度

			uni.getSystemInfo({

				success: res => {

					this.windowHeight = res.windowHeight;

				}

			});

		},

		mounted() {

			this.setNavTop('.navBox')



			this.polyline = [{

				points: this.coordinate,

				color: '#025ADD',

				width: 4,

				dottedLine: false,

			}];

		},

		methods: {

			setNavTop(style) {

				let view = uni.createSelectorQuery().select(style);

				view

					.boundingClientRect((data) => {

						console.log("tabInList基本信息 = " + data.height);

						this.mapHeight = this.windowHeight - data.height;

						console.log(this.mapHeight);

					})

					.exec();

			},

			start() {

				if (this.movementInterval) {

					clearInterval(this.movementInterval);

				}

				this.isStart = true;

				this.moveMarker();

			},

			moveMarker() {

				if (!this.isStart) return;



				if (this.playIndex >= this.coordinate.length) {

					this.playIndex = 0;

					uni.showToast({

						title: "播放完成",

						duration: 1400,

						icon: "none",

					});

					this.isStart = false;

					this.isDisabled = false;

					return;

				}



				let datai = this.coordinate[this.playIndex];

				this.map.translateMarker({

					markerId: 1,

					autoRotate: true,

					destination: {

						longitude: datai.longitude,

						latitude: datai.latitude,

					},

					duration: 700,

					complete: () => {

						this.playIndex++;

						this.moveMarker();

					},

				});

			},

			pause() {

				this.isStart = false;

				this.isDisabled = false;

				if (this.movementInterval) {

					clearInterval(this.movementInterval);

					this.movementInterval = null;

				}

			},

		}

	}

</script>



<style lang="scss" scoped>

	.container {

		position: relative;

	}



	.btnBox {

		width: 750rpx;

		position: absolute;

		bottom: 60rpx;

		z-index: 99;

		display: flex;

		justify-content: space-around;

	}

</style>