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

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 这样的攻击就能安枕无忧。

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

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

Sa-Token 是一个轻量级 Java 权限认证框架，主要解决：登录认证、权限认证、单点登录、OAuth2.0、微服务网关鉴权 等一系列权限相关问题。🔐

目前最新版本 v1.41.0 已推送至 Maven 中央仓库 🎉，大家可以通过如下方式引入：

<!-- Sa-Token 权限认证 -->

<dependency>

    <groupId>cn.dev33</groupId>

    <artifactId>sa-token-spring-boot-starter</artifactId>

    <version>1.41.0</version>

</dependency>

该版本包含大量 ⛏️️️新增特性、⛏️底层重构、⛏️️️代码优化 等，下面容我列举几条比较重要的更新内容供大家参阅：

🛡️ 更新点1：防火墙模块新增 hooks 扩展机制

本次更新针对防火墙新增了多条校验规则，之前的规则为：

• path 白名单放行。


• path 黑名单拦截。


• path 危险字符校验。

本次新增规则为：

• path 禁止字符校验。


• path 目录遍历符检测（优化了检测算法）。


• 请求 host 检测。


• 请求 Method 检测。


• 请求 Header 头检测。


• 请求参数检测。

并且本次更新开放了 hooks 机制，允许开发者注册自定义的校验规则 🛠️，参考如下：

@PostConstruct

public void saTokenPostConstruct() {

    // 注册新 hook 演示，拦截所有带有 pwd 参数的请求，拒绝响应 

    SaFirewallStrategy.instance.registerHook((req, res, extArg)->{

        if(req.getParam("pwd") != null) {

            throw new FirewallCheckException("请求中不可包含 pwd 参数");

        }

    });

}

文档直达地址：Sa-Token 防火墙 🔗

💡 更新点2：新增基于 SPI 机制的插件体系

之前在 Sa-Token 中也有插件体系，不过都是利用 SpringBoot 的 SPI 机制完成组件注册的。

这种注册机制有一个问题，就是插件只能在 SpringBoot 环境下正常工作，在其它环境，比如 Solon 项目中，就只能手动注册插件才行 😫。

也就是说，严格来讲，这些插件只能算是 SpringBoot 的插件，而非 Sa-Token 框架的插件 🌐。

为了提高插件的通用性，Sa-Token 设计了自己的 SPI 机制，使得这些插件可以在更多的项目环境下正常工作 🚀。

第一步：实现插件注册类，此类需要 implements SaTokenPlugin 接口 👨💻：

/**

 * SaToken 插件安装：插件作用描述

 */

public class SaTokenPluginForXxx implements SaTokenPlugin {

    @Override

    public void install() {

        // 书写需要在项目启动时执行的代码，例如：

        // SaManager.setXxx(new SaXxxForXxx());

    }

}

第二步：在项目的 resources\META-INF\satoken\ 文件夹下 📂 创建 cn.dev33.satoken.plugin.SaTokenPlugin 文件，内容为该插件注册类的完全限定名：

cn.dev33.satoken.plugin.SaTokenPluginForXxx

这样便可以在项目启动时，被 Sa-Token 插件管理器加载到此插件，执行插件注册类的 install 方法，完成插件安装 ✅。

文档直达地址：Sa-Token 插件开发指南 🔗

🎛️ 更新点3：重构缓存体系，将数据读写与序列化操作分离

在之前的版本中，Redis 集成通常和具体的序列化方式耦合在一起，这不仅让 Redis 相关插件产生大量的重复冗余代码，也让大家在选择 Redis 插件时严重受限。⚠️

本次版本更新彻底重构了此模块，将数据读写与序列化操作分离，使其每一块都可以单独自定义实现类，做到灵活扩展 ✨，例如：

• 1️⃣ SaTokenDao 数据读写可以选择：RedisTemplate、Redisson、ConcurrentHashMap、Hutool-Timed-Cache 等不同实现类。


• 2️⃣ SaSerializerTemplate 序列化器可以选择：Base64编码、Hex编码、ISO-8859-1编码、JSON序列化等不同方式。


• 3️⃣ JSON 序列化可以选择：Jackson、Fastjson、Snack3 等组件。

所有实现类均可以按需选择，自由搭配，大大提高灵活性🏗️。

⚙️️ 更新点4：SaLoginParameter 登录参数类新增大量配置项

SaLoginParameter (前SaLoginModel) 用于控制登录操作中的部分细节行为，本次新增的配置项有：

• isConcurrent：决定是否允许同一账号多地同时登录（为 true 时允许一起登录, 为 false 时新登录挤掉旧登录）。🌍


• isShare：在多人登录同一账号时，是否共用一个 token （为 true 时所有登录共用一个 token, 为 false 时每次登录新建一个 token）。🔄


• maxLoginCount：同一账号最大登录数量，超出此数量的客户端将被自动注销，-1代表不限制数量。🚫


• maxTryTimes：在创建 token 时的最高循环次数，用于保证 token 唯一性（-1=不循环尝试，直接使用。⏳


• deviceId：此次登录的客户端设备id，用于判断后续某次登录是否为可信任设备。📱


• terminalExtraData：本次登录挂载到 SaTerminalInfo 的自定义扩展数据。📦

以上大部分配置项在之前的版本中也有支持，不过它们都被定义在了全局配置类 SaTokenConfig 之上，本次更新支持在 SaLoginParameter 中定义这些配置项，
这将让登录策略的控制变得更加灵活。✨

🚪 更新点5：新增 SaLogoutParameter 注销参数类

SaLogoutParameter 用于控制注销操作中的部分细节行为️，例如：

通过 Range 参数决定注销范围 🎯：

// 注销范围： TOKEN=只注销当前 token 的会话，ACCOUNT=注销当前 token 指向的 loginId 其所有客户端会话

StpUtil.logout(new SaLogoutParameter().setRange(SaLogoutRange.TOKEN));

通过 DeviceType 参数决定哪些登录设备类型参与注销 💻：

// 指定 10001 账号，所有 PC 端注销下线，其它端如 APP 端不受影响 

StpUtil.logout(10001, new SaLogoutParameter().setDeviceType("PC"));

还有其它参数此处暂不逐一列举，文档直达地址：Sa-Token 登录参数 & 注销参数 🔗

🐞 更新点6：修复 StpUtil.setTokenValue("xxx")、loginParameter.getIsWriteHeader() 空指针的问题。

这个没啥好说的，有 bug 🐛 必须修复。

fix issue：#IBKSM0 🔗

✨ 更新点7：API 参数签名模块升级

• 1、新增了 @SaCheckSign 注解，现在 API 参数签名模块也支持注解鉴权了。🆕


• 2、新增自定义签名的摘要算法，现在不仅可以 md5 算法计算签名，也支持 sha1、sha256 等算法了。🔐


• 3、新增多应用模式：

多应用模式就是指，允许在对接多个系统时分别使用不同的秘钥等配置项，配置示例如下 📝：

sa-token: 

    # API 签名配置 多应用模式

    sign-many:

        # 应用1

        xm-shop:

            secret-key: 0123456789abcdefg

            digest-algo: md5

        # 应用2

        xm-forum:

            secret-key: 0123456789hijklmnopq

            digest-algo: sha256

        # 应用3

        xm-video:

            secret-key: 12341234aaaaccccdddd

            digest-algo: sha512

然后在签名时通过指定 appid 的方式获取对应的 SignTemplate 进行操作 👨💻：

// 创建签名示例

String paramStr = SaSignMany.getSignTemplate("xm-shop").addSignParamsAndJoin(paramMap);



// 校验签名示例

SaSignMany.getSignTemplate("xm-shop").checkRequest(SaHolder.getRequest());

⚡ 更新点8：新增 sa-token-caffeine 插件，用于整合 Caffeine

Caffeine 是一个基于 Java 的高性能本地缓存库，本次新增 sa-token-caffeine 插件用于将 Caffeine 作为 Sa-Token 的缓存层，存储会话鉴权数据。🚀
这进一步丰富了 Sa-Token 的缓存层插件生态。🌱

<!-- Sa-Token 整合 Caffeine -->

<dependency>

    <groupId>cn.dev33</groupId>

    <artifactId>sa-token-caffeine</artifactId>

    <version>1.41.0</version>

</dependency>

🎪 更新点9：新增 sa-token-serializer-features 序列化扩展包

引入此插件可以为 Sa-Token 提供一些有意思的序列化方案。（娱乐向，不建议上生产 🎭）

例如：以base64 编码，采用：元素周期表 🧪、特殊符号 🔣、或 emoji 😊 作为元字符集存储数据 ：

📜 完整更新日志

除了以上提到的几点以外，还有更多更新点无法逐一详细介绍，下面是 v1.41.0 版本的完整更新日志：

• core:
  
  
  
  • 修复：修复 StpUtil.setTokenValue("xxx")、loginParameter.getIsWriteHeader() 空指针的问题。 fix: #IBKSM0
  
  
  • 修复：将 SaDisableWrapperInfo.createNotDisabled() 默认返回值封禁等级改为 -2，以保证向之前版本兼容。
  
  
  • 新增：新增基于 SPI 的插件体系。 [重要]
  
  
  • 重构：JSON 转换器模块。 [重要]
  
  
  • 新增：新增 serializer 序列化模块，控制 Object 与 String 的序列化方式。 [重要]
  
  
  • 重构：重构防火墙模块，增加 hooks 机制。 [重要]
  
  
  • 新增：防火墙新增：请求 path 禁止字符校验、Host 检测、请求 Method 检测、请求头检测、请求参数检测。重构目录遍历符检测算法。
  
  
  • 重构：重构 SaTokenDao 模块，将序列化与存储操作分离。 [重要]
  
  
  • 重构：重构 SaTokenDao 默认实现类，优化底层设计。
  
  
  • 新增：isLastingCookie 配置项支持在全局配置中定义了。
  
  
  • 重构：SaLoginModel -> SaLoginParameter。 [不向下兼容]
  
  
  • 重构：TokenSign -> SaTerminalInfo。 [不向下兼容]
  
  
  • 新增：SaTerminalInfo 新增 extraData 自定义扩展数据设置。
  
  
  • 新增：SaLoginParameter 支持配置 isConcurrent、isShare、maxLoginCount、maxTryTimes。
  
  
  • 新增：新增 SaLogoutParameter，用于控制注销会话时的各种细节。 [重要]
  
  
  • 新增：新增 StpLogic#isTrustDeviceId 方法，用于判断指定设备是否为可信任设备。
  
  
  • 新增：新增 StpUtil.getTerminalListByLoginId(loginId)、StpUtil.forEachTerminalList(loginId) 方法，以更方便的实现单账号会话管理。
  
  
  • 升级：API 参数签名配置支持自定义摘要算法。
  
  
  • 新增：新增 @SaCheckSign 注解鉴权，用于 API 签名参数校验。
  
  
  • 新增：API 参数签名模块新增多应用模式。 fix: #IAK2BI, #I9SPI1, #IAC0P9 [重要]
  
  
  • 重构：全局配置 is-share 默认值改为 false。 [不向下兼容]
  
  
  • 重构：踢人下线、顶人下线默认将删除对应的 token-session 对象。
  
  
  • 优化：优化注销会话相关 API。
  
  
  • 重构：登录默认设备类型值改为 DEF。 [不向下兼容]
  
  
  • 重构：BCrypt 标注为 @Deprecated。
  
  
  • 新增：sa-token-quick-login 支持 SpringBoot3 项目。 fix: #IAFQNE、#673
  
  
  • 新增：SaTokenConfig 新增 replacedRange、overflowLogoutMode、logoutRange、isLogoutKeepFreezeOps、isLogoutKeepTokenSession 配置项。
  
  
  
  


• OAuth2：
  
  
  
  • 重构：重构 sa-token-oauth2 插件，使注解鉴权处理器的注册过程改为 SPI 插件加载。
  
  
  
  


• 插件：
  
  
  
  • 新增：sa-token-serializer-features 插件，用于实现各种形式的自定义字符集序列化方案。
  
  
  • 新增：sa-token-fastjson 插件。
  
  
  • 新增：sa-token-fastjson2 插件。
  
  
  • 新增：sa-token-snack3 插件。
  
  
  • 新增：sa-token-caffeine 插件。
  
  
  
  


• 单元测试：
  
  
  
  • 新增：sa-token-json-test json 模块单元测试。
  
  
  • 新增：sa-token-serializer-test 序列化模块单元测试。
  
  
  
  


• 文档：
  
  
  
  • 新增：QA “多个项目共用同一个 redis，怎么防止冲突？”
  
  
  • 优化：补全 OAuth2 模块遗漏的相关配置项。
  
  
  • 优化：优化 OAuth2 简述章节描述文档。
  
  
  • 优化：完善 “SSO 用户数据同步 / 迁移” 章节文档。
  
  
  • 修正：补全项目目录结构介绍文档。
  
  
  • 新增：文档新增 “登录参数 & 注销参数” 章节。
  
  
  • 优化：优化“技术求助”按钮的提示文字。
  
  
  • 新增：新增 preview-doc.bat 文件，一键启动文档预览。
  
  
  • 完善：完善 Redis 集成文档。
  
  
  • 新增：新增单账号会话查询的操作示例。
  
  
  • 新增：新增顶人下线 API 介绍。
  
  
  • 新增：新增 自定义序列化插件 章节。
  
  
  
  


• 其它：
  
  
  
  • 新增：新增 sa-token-demo/pom.xml 以便在 idea 中一键导入所有 demo 项目。
  
  
  • 删除：删除不必要的 .gitignore 文件
  
  
  • 重构：重构 sa-token-solon-plugin 插件。
  
  
  • 新增：新增设备锁登录示例。
  
  
  
  

更新日志在线文档直达链接：sa-token.cc/doc.html#/m…

🌟 其它

代码仓库地址：gitee.com/dromara/sa-…

框架功能结构图：

得益于 Cursor 从 v0.45.x 开始支持 Anthropic MCP 协议，最近 MCP server 的概念很火热。我想聊聊对这个协议的感受。

MCP 是什么？

MCP = Model Context Protocol = 模型上下文协议

说白了，它就是个「插件协议」，严谨点加个限定词，「专供 LLM 应用的插件接口协议」。

Anthropic 官方说 MCP 是受微软的 LSP (Language Service Protocol) 的启发而制定，有朋友熟悉 LSP 协议的话，应该马上会发现这两者极为相似。

给不了解 LSP 的朋友介绍一下。VSCode 大家都熟，可以装各种插件。因为 VSCode 是用 JS 写的，插件要运行在 VSCode 之内，所以也必须用 JS 写。

但有一类插件比较特殊：编程语言支持类插件。比如你想在 VSCode 里写 rust，肯定要装 rust 相关插件。可问题是 rust 官方的语言支持（提供错误提示、代码自动补全之类的功能）肯定也是用 rust 写的，无法直接跑在 VSCode 的运行时里。别的语言 C#、Java、Python 情况也一样，怎么办呢？

为了解决这问题，LSP 制定了一套基于 JSON-RPC 2.0 的标准协议。RPC 顾名思义「远程调用」，那些语言工具你爱跑在哪都行，只要你按照这协议，能接受 RPC 请求，能给出正确返回数据格式，那么就能顺利接入 VSCode。

这套协议带来的价值有三个点：

所以 MCP 到底是什么…

之所以在 LSP 上费这么多字，是希望能借用一个大家熟悉的老概念，快速对 MCP 这个新概念建立起一个直观的认识。

回到 MCP，它也是一个基于 JSON-RPC 2.0 的标准协议，LSP 有的那些优点它也有：

• 开放标准：语言无关，实现无关，有助形成开放生态


• 解耦合：只要客户端支持，你的 MCP Server 都能接入，不用多次适配


• 最佳实践：参考「标准功能」，能借鉴行业集体经验，少走弯路

我认为「标准功能」，官方称为「能力（capability）」，是 MCP 价值比较大的东西，尤其对于开发 LLM 应用的朋友来说，支持这些能力基本上就跟 Cursor 在底层的 agent 工具层面上对齐了。

MCP 不是什么

MCP 不是 agent 框架，MCP 也不是 RAG 框架，它甚至都不是框架！尽管官方有提供 SDK，但 MCP 本身只是一个标准协议，目的是构建一个给 LLM/agent 用的「外接能力插件生态」。

不过 MCP 的标准设计里没有考虑 RAG 能力，是让我比较困惑的点。

能力 Capability

理解这个小节，我建议脑子里可以想着 Cursor 作为「LLM 应用」的范本。

client 端能力

• roots 当前项目路径列表，对标 IDE 里的 workspace/project 概念，主要用来通知 server 端更新 resources（见下文）


• sampling 供 server 调用 client 侧 LLM 的能力

server 端能力

• tools 任意的外部工具：计算器、代码运行、搜索引擎之类


• prompts 提示词模版，设计目的是为了支持类似 Github Copilot Chat 聊天框 / 开头的快捷指令
  
  


• resources 当前项目下有什么资源可访问（主要是文件啦）。Cursor/Cline 聊天框 @/foobar.txt 就可以用这项能力来实现
  


• completion 自动补全，快捷指令和资源都需要，提升用户体验


• logging 给到 client 的 log 信息推送，这个属于杂项，方便 debug 之类

其他

• resources 不只能建模文件，也可以建模 git 历史，数据库表等其他资源，只需要 uri 上通过 "git://" 或 "db://" 来区分即可


• 两端都支持自定义能力，通过 experimental namespace 来暴露。


• 前面提过 MCP 没考虑 RAG 的用例，目前看来似乎可以通过 prompts + completion 能力来间接实现。

通讯模型

MCP 是一个 client/server 架构的 RPC 协议，需要关注两端的通讯模型。大致可分三段生命周期来看：初始化阶段，运行阶段，结束阶段。不过先铺垫两个前置知识，方便后面的理解。

前置知识

一、实体术语定义

一共有三类实体：host, client, server.

host 指「LLM 应用」的本体，它大概率是个 GUI 程序。在 MCP 的语境下，这就是一个容器，负责管理多个 client 实例，同时要集成 LLM，承接用户交互，特别是各种授权的工作。

每个 client 实例只负责与一个 server 建立有状态的连接，然后进行 RPC 通讯。server 是实际干活的、跑插件的线程，client 是留在 host 内负责 RPC 调用的一段简单的程序。

当前的协议版本下（版本号：2024-11-05，你没看错，它是用日期来做版本号的）

• host 与 client 是一对多关系


• client 与 server 是一对一关系

这里插一句，「一对一」的奇怪设定是暂时的。目前 MCP 只针对 client/server 都跑在本地的场景设计，官方 SDK 在使用 stdio 为传输信道的时候，更是做了个「由 client fork 子进程来跑 server」的强假设。好在 roadmap 里面有提，支持 remote server 是眼下的第一优先级，预计 2025 上半年会更新相关标准。

二、JSON-RPC 2.0 的三种信息类型

JSON-RPC 2.0 标准有三类 RPC 信息类型：request, response, notification. 注意几个点：

• request 必须有对应 response, id 要对得上


• response 的 result 和 error 字段互斥，同时只可能有其一


• response error.code 必须是整数，并且协议预留了一批错误码，代表特定含义（类似 HTTP status code）


• notification 只比 request 少一个 id, 并且不要求有对应 response

type JsonRpcRequest = {

  jsonrpc: "2.0";

  id: string | number;

  method: string;

  params?: {

    [key: string]: unknown;

  };

};



type JsonRpcResponse = {

  jsonrpc: "2.0";

  id: string | number;

  // result 与 error 是互斥的

  result?: {

    [key: string]: unknown;

  };

  error?: {

    code: number;

    message: string;

    data?: unknown;

  };

};



type JsonRpcNotification = {

  jsonrpc: "2.0";

  method: string;

  params?: {

    [key: string]: unknown;

  };

};

三个通讯生命周期

一、初始化阶段 Initialization

client/server 需要握手协商，交换各自能力（capability）声明，跟 TCP 的三次握手基本一样。

第一次：client 向 server 发送 request，声明 client 侧提供的能力。

Client：「Server 老哥在吗？我能干这些，你能干啥？」

第二次：server 向 client 回复 response，声明 server 侧提供的能力。

Server：「Client 老弟，我在呢，我能干这些，需要干啥活你喊我哈！」

第三次：client 向 server 发送 notification，确认连接建立

Client：「得嘞，那我开始干活了，有事儿我再喊你。」

二、运行阶段 Operation

根据初始化阶段交换的能力声明，两端开始互相发送 RPC 信息。这里展示一段能力调用示例。

// 1. server 在初始化阶段，第二次握手时，向 client 公布自己的 tools 能力

{

  "capabilities": {

    "tools": {

      "listChanged": true

    }

  }

}



// 2. client 初始化后，主动拉取 tools 列表

// Request:

{

  "jsonrpc": "2.0",

  "id": 1,

  "method": "tools/list",

  "params": {

    // 可选参数，list 如果很长，可支持翻页

    "cursor": "optional-cursor-value"

  }

}

// Response:

{

  "jsonrpc": "2.0",

  "id": 1,

  "result": {

    "tools": [

      {

        "name": "get_weather",

        "description": "Get current weather information for a location",

        "inputSchema": {

          "type": "object",

          "properties": {

            "location": {

              "type": "string",

              "description": "City name or zip code"

            }

          },

          "required": ["location"]

        }

      }

    ],

    "nextCursor": "next-page-cursor"

  }

}



// 3. client 调用工具

// Request:

{

  "jsonrpc": "2.0",

  "id": 2,

  "method": "tools/call",

  "params": {

    "name": "get_weather",

    "arguments": {

      "location": "New York"

    }

  }

}

// Response:

{

  "jsonrpc": "2.0",

  "id": 2,

  "result": {

    "content": [

      {

        "type": "text",

        "text": "Current weather in New York:\nTemperature: 72°F\nConditions: Partly cloudy"

      }

    ],

    "isError": false

  }

}



// 4. 如果 server 端因为什么原因，可用 tools list 发生变化，应该通知 client 重新拉取

{

  "jsonrpc": "2.0",

  "method": "notifications/tools/list_changed"

}

三、结束阶段 Shutdown

标准只说任何一端（正常来说是 client 端）可以主动断开连接，没有硬性规定这个阶段的具体协议。因为传输层通常会有相关的断联信号，已经够用了，没必要再在上层协议重复建设。

但是实际写落地实现，开发者还是需要做一些处理的，比如 graceful shutdown, 或者错误重启之类的。

总结

目前整个 AI 应用范式没有固定下来，整个业界都在积极探索，摸着石头过河。这个背景下 MCP 相当于把 AI 应用厂商们拉了个大群，一起来总结业界的最佳实践，制定标准推广集体智慧。当前 MCP 的生态发展势头很不错，标准本身更新得也很紧跟潮流。最近当红炸子鸡 Cursor 的加入，可以说是对 MCP 的重大利好，势必会进一步刺激 MCP server（插件）生态的成长。

现在正在做 LLM 相关应用的朋友，我非常推荐拥抱这个协议标准，好处多多。

如果觉得本文对你有帮助，欢迎转发和关注（微信公众号同名），我会持续分享在开发 multi-agent 系统过程中的第一手经验和心得。

前言

本文主要介绍 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 自动更新的文章，在做这个需求之前也是浏览了好多，但也有些没仔细看完，所以就躺在我的标签页没有关闭，在这罗列出来，也当作收藏了。

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

鸣谢：

先说结论：
在绝大部分的业务前端开发中，写单元测试的收益非常小，但是带来的维护成本却非常大，请不要再写单元测试感动自己，为难同事了。

现在很多单元测试的教程都是那种很简单的比如，测个 1+1=2，这需要测吗？下面这段代码已经出现过很多次了，纯纯的误导人。

const sum = (a,b) => a+b

it('1+1=2',()=> {

    expect(sum(1,1)).toBe(2)

})

稍微上点复杂度，来写个组件的单测，比如一个用户信息展示组件，叫 UserInfoBlock，支持设置头像的大小，点击名字支持跳转到个人主页，组件代码大致长这样

interface UserInfoBlockProps {

    name: string

    size: 16 | 24

    id: string

    icon: string

}

export const UserInfoBlock:FC<UserInfoBlockProps> = (props) => {

    const navigate = useNavigate()

    return <div 

            class='xxxxxx' 

            style={{width: props.size}} 

            onClick={() => {navigate(`/user/${props.id}`)}}>

                <img src={props.icon}/>

                {props.name}

            </div>

}

然后开始给组件写单测，先测头像大小的功能

import { UserInfoBlock, UserInfoBlockProps } from './user-info-block'

import { fireEvent, render, screen } from '@testing-library/react'

describe('UserInfoBlock 组件单测', () => {

    const userInfo:UserInfoBlockProps = {

        name: '张三',

        icon:'https://xxx.png',

        id:'abcd1234',

        size: 16

    }

    const userInfoLarge:UserInfoBlockProps = {

        name: '张三',

        icon:'https://xxx.png',

        id:'abcd1234',

        size: 24

    }

    describe('展示默认头像大小', () => {

        const component = render(<UserInfoBlock {...userInfo}/>)

        it('img 标签的宽度为 16px', () => {

            expect(screen.getByTag('img').style.width).toBe(16)

        })

    })

    describe('展示large头像大小', () => {

        const component = render(<UserInfoBlock {...userInfoLarge}/>)

        it('img 标签的宽度为 24px', () => {

            expect(screen.getByTag('img').style.width).toBe(24)

        })

    })

})

接下来测一下跳转，因为用了 react-router，所以在渲染组件的时候必须包裹一下 RouterProvider

...

    describe('点击可以跳转', () => {

        const component = render(<MemoryRouter>

            <UserInfoBlock {...userInfoLarge}/>

        </MemoryRouter>

        )

        fireEvent.click(component.div)

        it('url 会变成 user/abcd1234', () => {

            expect(location.pathname).toBe('user/abcd1234')

        })

    })

...

这个组件的测试就写完了，看起来挺有用，但实际没啥用。

首先这个测试的收益不高，因为这是一个很简单的组件，五分钟写完，但是写这个测试需要翻倍的时间，因为需要构造数据，之前没有经验不知道要加 MemoryRouter，jest 测 location 对象不方便，还要 mock 一下。等把这一套搞完了才能跑通，这就好像你疯狂锻炼，练出麒麟臂，就是为了举自拍杆举的稳一点。如果组件内要发请求，要做的准备工作就更加多了。

其次，user/abcd1234是什么，断言这个没用，因为别人改了链接，你的测试也一样会过，应该断言成功的打开了用户主页，比如断言一个必定会存在的文字expect(screen.getByText('用户详情')).toBeInDocument()这才能证明真的打开了用户主页。

1+1 什么时候不等于 2。头像设置 16px，什么时候不会是 16 px。什么时候点击不跳转到用户主页。肯定是有人修改了这里的业务逻辑才会这样，只有在做产品需求，代码优化的时候才会去改以前的代码。那么这时，这段测试对接手这段代码的人就是负担。

假设我接到需求，用户主页url 变了，改成 user?id=xxx。我心想这个简单，一秒钟解决，提了 pr 发现测试挂了，然后我就得把测试也改一下。

如果一段测试代码在我每次修改需求的时候都要改，甚至有的时候还会为了便于测试在业务代码中留一些后门，那这个测试就是纯纯的副作用。

大家肯定深有体会，一般一个模块自己不会出问题，但是多个模块组合起来就很容易出问题了，所以测试的重点不应该是一个组件内部各种细节，而应该测这个组件在被使用的地方是否正确。

举个例子，比如在一个列表里面，使用头像为 24px 的用户组件，然后有一天出 bug 了，说这里变成 16 了。那这会是组件的 bug 吗，这肯定是使用的地方没有用对。所以应该要测试的是这里。如果有个测试断言了在列表中用户头像必须为 24px，即使没有组件的单测，这个组件也不会被改坏，因为上层已经覆盖到了。

什么是好的测试？

那么怎么写出这样的测试呢？答案就是写集成测试，集成测试说白了就是一个超级大的单测，之前测试 render 的是一个组件，现在直接 render(<App/>)，将路由跳转，请求 mock，fake数据库等等都统一处理。可以将上面写的测试简单的改为

import { creatAppContext, AppContext } from './app-test-context'

describe('S: 测试头像组件', () => {

    let _:AppContext

    beforeEach(() => {

        - = creatAppContext()

    })

    describe('W: 去用户列表也', () => {

        beforeEach(() => {

            _.click(screen.getByText('查看用户列表'))

        })

        it('T: 列表页有十个用户，用户头像是 24px', ()=>{

            expect(screen.getAllByTestid('user-item').length).toBe(10)

            expect(screen.getAllByTestid('user-item')[0].img.style.width).toBe(24)

        })

        describe('W: 点击第一个用户', () => {

            beforeEach(() => {

                _.click(screen.getAllByTestid('user-item')[0])

            })

            it('T: 打开了用户主页', () => {

                expect(screen.getByText('用户详情')).toBeInDocument()

            })

        })

    })

})

关于怎么写好测试可以展开的点实在太多了，就不过多阐述，想要了解的朋友可以查看我的主页，之前专门出过一些列文章详细的讲这些事情。

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

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

一、命运的齿轮开始转动

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

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

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

auto-i18n-translation-plugins

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

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

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

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