npm install systeminformation

const si = require('systeminformation');



// 获取 CPU 信息

si.cpu()

  .then(data => console.log(data))

  .catch(error => console.error(error));



// 获取内存信息

si.mem()

  .then(data => console.log(data))

  .catch(error => console.error(error));



// 获取操作系统信息

si.osInfo()

  .then(data => console.log(data))

  .catch(error => console.error(error));

• 3. 实时监控示例

const si = require('systeminformation');



// 实时监控 CPU 使用率

setInterval(() => {

  si.currentLoad()

    .then(data => console.log(`CPU Load: ${data.currentload}%`))

    .catch(error => console.error(error));

}, 1000);



// 实时监控内存使用情况

setInterval(() => {

  si.mem()

    .then(data => console.log(`Memory Usage: ${data.used / data.total * 100}%`))

    .catch(error => console.error(error));

}, 1000);

结语

systeminformation 是一个功能强大且灵活的 Node.js 库，能够帮助你轻松获取系统的各种信息。无论你是需要实时监控服务器性能，还是需要获取本地系统的详细信息，systeminformation 都能为你提供稳定且易用的解决方案。

希望这篇文章能帮助你了解 systeminformation 的强大功能，并激发你在项目中使用它的灵感。赶快分享给你的朋友们吧！

前言

在JavaScript中，类型判断是一个非常基础但也十分重要的知识点。不同的类型判断方法适用于不同的场景，掌握这些方法可以帮助我们更好地理解和使用JavaScript。本文将详细介绍typeof、instanceof、Object.prototype.toString以及Array.isArray这四种常用的类型判断方法，并通过实例代码帮助大家加深理解。

正文

typeof

typeof操作符可以用来判断基本数据类型，如string、number、boolean、undefined、symbol、bigint等。它对于null和所有引用类型的判断会返回"object"，而对于函数则会返回"function"。

特点：

示例代码：

let s = '123'; // string

let n = 123; // number

let f = true; // boolean

let u = undefined; // undefined

let nu = null; // null

let sy = Symbol(123); // Symbol

let big = 1234n; // BigInt



console.log(typeof s); // "string"

console.log(typeof n); // "number"

console.log(typeof f); // "boolean"

console.log(typeof u); // "undefined"

console.log(typeof sy); // "symbol"

console.log(typeof big); // "bigint"

console.log(typeof nu); // "object" - 特殊情况



let obj = {};

let arr = [];

let fn = function() {};

let date = new Date();



console.log(typeof obj); // "object"

console.log(typeof arr); // "object"

console.log(typeof date); // "object"

console.log(typeof fn); // "function"



function isObject(o) {

  if (typeof o === 'object' && o !== null) {

    return true;

  }

  return false;

}



let res = isObject({a: 1});

console.log(res); // true

instanceof

instanceof用于检测构造函数的prototype属性是否出现在某个实例对象的原型链上。因此，它主要用于判断引用类型。

特点：

示例代码：

let obj = {};

let arr = [];

let fn = function() {};

let date = new Date();



console.log(obj instanceof Object); // true

console.log(arr instanceof Array); // true

console.log(fn instanceof Function); // true

console.log(date instanceof Date); // true

console.log(arr instanceof Object); // true



console.log(arr instanceof String); // false

console.log(n instanceof Number); // false

因为原始类型没有原型而引用类型有原型，所有instanceof主要用于判断引用类型，那么根据这个我们是不是可以手写一个instanceof。

手写·instanceof实现：

首先我们要知道v8创建对象自变量是这样的，拿let arr = []举例子：

function createArray() {

    // 创建一个新的对象

    let arr = new Array();

    // 设置原型

    arr.__proto__ = Array.prototype;

    // 返回创建的数组对象

    return arr;

  }

V8 引擎会调用 Array 构造函数来创建一个新的数组对象，Array 构造函数的内部实现会创建一个新的空数组对象，并初始化其内部属性并且将新创建的数组对象的 __proto__ 属性设置为 Array.prototype，这意味着数组对象会继承 Array.prototype 上的所有方法和属性，最后，新创建的数组对象会被赋值给变量 arr。

那么我们是不是可以通过实例对象的隐式原型等于其构造函数的显式原型来判断类型，代码如下：

function myInstanceOf(L,R){

    if(L.__proto__ === R.prototype){

        return true;

    }

    return false;

}

但是我们看到console.log([] instanceof Object); // true,所有还要改进一下：

我们要知道这么一件事情：

所以我们是不是可以这样：

function myinstanceof(L, R) {

  while (L !== null) {

    if (L.__proto__ === R.prototype) {

      return true;

    }

    L = L.__proto__;

  }

  return false;

}



console.log(myinstanceof([], Array));  // true

console.log(myinstanceof([], Object));  // true

console.log(myinstanceof({}, Array));  // false

所以就完美实现了。

Object.prototype.toString.call

Object.prototype.toString.call 是一个非常有用的工具，可以用来获取任何 JavaScript 值的类型信息。它结合了 Object.prototype.toString 和 Function.prototype.call 两个方法的功能。

特点：

代码示例

console.log(Object.prototype.toString.call(null));       // [object Null]

console.log(Object.prototype.toString.call(123));        // [object Number]

console.log(Object.prototype.toString.call([]));         // [object Array]

console.log(Object.prototype.toString.call({}));         // [object Object]

console.log(Object.prototype.toString.call('hello'));    // [object String]

console.log(Object.prototype.toString.call(true));       // [object Boolean]

console.log(Object.prototype.toString.call(undefined));  // [object Undefined]

console.log(Object.prototype.toString.call(Symbol()));   // [object Symbol]

console.log(Object.prototype.toString.call(123n));       // [object BigInt]

Object.prototype.toString

底层逻辑

根据官方文档，Object.prototype.toString 方法的执行步骤如下：

关键点解释

• ToObject 方法：将传入的值转换为对象。对于原始类型（如 string、number、boolean），会创建对应的包装对象（如 String、Number、Boolean）。对于 null 和 undefined，会有特殊处理。


• [[Class]] 内部属性：每个对象都有一个 [[Class]] 内部属性，表示对象的类型。例如，数组的 [[Class]] 值为 "Array"，对象的 [[Class]] 值为 "Object"。

console.log(Object.prototype.toString(123));//[object Object]

console.log(Object.prototype.toString('123'));//[object Object]

console.log(Object.prototype.toString({}));//[object Object]

console.log(Object.prototype.toString([]));//[object Object]

为什么需要 call？

Object.prototype.toString 方法默认的 this 值是 Object.prototype 本身。如果我们直接调用 Object.prototype.toString(123)，this 值仍然是 Object.prototype，而不是我们传入的值。因此，我们需要使用 call 方法来改变 this 值，使其指向我们传入的值。

手写call

obj = {

    a:1,

}



function foo(){

    console.log(this.a);

}



//我们需要将foo中的this指向obj里面

Function.prototype.myCall = function(context){

    if(!(this instanceof Function)){    在构造函数原型上，this指向的是实例对象,这里即foo

        return new TypeError(this+'is not function')

    }

 

    const fn = Symbol('key'); //使用symbol作为key是因为可能会同名

    context[fn] = this;//添加变量名为fn，值为上面的,context={Symbol('key'): foo}

    context[fn](); // 触发了隐式绑定

    delete context[fn]; //删除这个方法

}



foo.myCall(obj)    // 1

console.log(obj);  // {a:1}

我们知道call方法是将函数里面的this强行掰弯到我们传入的对象里面去，它的原理是这样的，首先判断你传入的参数是不是一个函数，因为只有函数身上才有call方法，函数调用然后通过隐式绑定规则，将this指向这个对象，那么不就强行更改了this的指向，[不知道this的可以看这篇文章](你不知道的JavaScript（核心知识点概念详细整理-掘金 (juejin.cn))

Array.isArray

Array.isArray是一个静态方法，用于检测给定的值是否为数组。

示例代码：

let arr = [];

let obj = {};



console.log(Array.isArray(arr)); // true

console.log(Array.isArray(obj)); // false

手写Array.isArray实现：

function myIsArray(value) {

  return Object.prototype.toString.call(value) === '[object Array]';

}



console.log(myIsArray(arr)); // true

console.log(myIsArray(obj)); // false

总结

• typeof适合用于检查基本数据类型，但对于null和对象类型的判断不够准确。


• instanceof用于检查对象的构造函数，适用于引用类型的判断。


• Object.prototype.toString提供了一种更通用的方法来判断所有类型的值。


• Array.isArray专门用于判断一个值是否为数组。

希望这篇文章能够帮助你更好地理解和使用JavaScript中的类型判断方法，感谢你的阅读!

你好呀，我是歪歪。

最近遇到一个生产问题，我负责的一个服务触发了内存使用率预警，收到预警的时候我去看了内存使用率已经到了 80%，看了一眼 GC 又发现还没有触发 FullGC，一次都没有。

基于这个现象，当时推测有两种可能，一种是内存溢出，一种是内存泄漏。

好，假设现在是面试，面试官目前就给了这点信息，他问你到底是溢出还是泄漏，你怎么回答？

在回答之前，我们得现明确啥是溢出，啥情况又是泄漏。

• 内存溢出（OutOfMemoryError）：内存溢出指的是程序请求的内存超出了 JVM 当前允许的最大内存容量。当 JVM 试图为一个对象分配内存时，如果当前可用的堆内存不足以满足需求，就会抛出 java.lang.OutOfMemoryError 异常。这通常是因为堆空间太小或者由于某些原因导致堆空间被占满。


• 内存泄漏 (Memory Leak)：内存泄漏是指不再使用的内存空间没有被释放，导致这部分内存无法再次被使用。虽然内存泄漏不会立即导致程序崩溃，但它会逐渐消耗可用内存，最终可能导致内存溢出。

虽然都与内存相关，但它们发生的时机和影响有所不同。内存溢出通常发生在程序运行时，当数据结构的大小超过预设限制时，常见的情况是你要分配一个大对象，比如一次从数据中查到了过多的数据。

而内存泄漏和“过多”关系不大，是一个细水长流的过程，一次内存泄漏的影响可能微乎其微，但随着时间推移，多次内存泄漏累积起来，最终可能导致内存溢出。

概念就是这个概念，这两个玩意经常被大家搞混，所以多嘴提一下。

概念明确了，回到最开始这个问题，你怎么回答？

你回答不了。

因为这些信息太不完整了，所以你回答不了。

面试的时候面试官就喜欢出这种全是错误选项的题目来迷惑你，摸摸你的底子到底怎么样。

首先，为什么不能判断，是因为前面说了：一次 FullGC 都没有。

虽然现在内存使用率已经到 80% 了，万一一次 FullGC 之后，内存使用率又下去了呢，说明程序没有任何问题。

如果没有下去，说明大概率是内存溢出了，需要去代码里面找哪里分配了大对象了。

那如果下去了，能说明一定没有内存泄漏吗？

也不能，因为前面又说了：内存泄漏是一个细水长流的过程。

关于内存溢出，如果监控手段齐全到位的话，你就记住左边这个走势图：

一个缓慢的持续上升的内存趋势图， 最后疯狂触发 GC，但是并没有内存被回收，最后程序直接崩掉。

内存泄漏，一眼定真假。

这个图来自我去年写的这篇文章：《虽然是我遇到的一个棘手的生产问题，但是我写出来之后，就是你的了。》

里面就是描述了一个内存泄漏的问题，通过分析 Dump 文件的方式，最终成功定位到泄漏点，修复代码。

一个不论多么复杂的内存泄漏问题，处理起来都是有方法论的。

不过就是 Dump 文件分析、工具的使用以及足够的耐心和些许的运气罢了。

所以我不打算赘述这些东西了，我想要分享的是我这次是怎么对应文章开始说的内存预警的。

我的处理方式就是：重启服务。

是的，常规来说都是会保留现场，然后重启服务。但是我的处理方式是：直接执行重启服务的预案。没有后续动作了。

我当时脑子里面的考虑大概是这样的。

首先，这个服务是一个边缘服务，它所承载的数据量不多，其业务已经超过一年多没有新增，存量数据正在慢慢的消亡。代码近一两年没啥改动，只有一些升级 jar 包，日志埋点这类的横向改造。

其次，我看了一下这个服务已经有超过四个月没有重启过了，这期间没有任何突发流量，每天处理的数据呈递减趋势，内存走势确实是一个缓慢上升的过程，我初步怀疑是有内存泄漏。

然后，这个服务是我从别的团队那边接手的一个服务，基于前一点，业务正在消亡这个因素，我也只是知道大概的功能，并不知道内部的细节，所以由于对系统的熟悉度不够，如果要定位问题，会较为困难。

最后，基于公司制度，虽然我知道应该怎么去排查问题，命令和工具我都会使用，但是我作为开发人员是没有权限使用运维人员的各类排查工具和排查命令的，所以如果要定位问题，我必须请求协调一个运维同事帮忙。

于是，在心里默默的盘算了一下投入产出比，我决定直接重启服务，不去定位问题。

按照目前的频率，程序正常运行四五个月后可能会触发内存预警，那么大不了就每隔三个月重启一次服务嘛，重启一次只需要 30s。一年按照重启 4 次算，也就是才 2 分钟。

这个业务我们就算它要五年后才彻底消亡，那么也就才 10 分钟而已。

如果我要去定位到底是不是内存泄露，到底在哪儿泄露的，结合我对于系统的熟悉程度和公司必须有的流程，这一波时间消耗，少说点，加起来得三五个工作日吧。

10 分钟和三五个工作日，这投入产出比，该选哪个，一目了然了吧？

我分享这个事情的目的，其实就是想说明我在这个事情上领悟到的一个点：在工作中，你遇到的问题，不是每一个都必须被解决的，也可以选择绕过问题，只要最终结果是好的就行。

如果我们抛开其他因素，只是从程序员的本职工作来看，那么遇到诸如内存泄漏的问题的时候，就是应该去定位问题、解决问题。

但是在职场中，其实还需要结合实际情况，进行分析。

什么是实际情况呢？

我前面列出来的那个“首先，其次，然后，最后”，就是我这个问题在技术之外的实际情况。

这些实际情况，让我决定不用去定位这个问题。

这也不是逃避问题，这是权衡利弊之后的最佳选择。

同样是一天的时间，我可以去定位这个“重启就能解决”的问题，也可以去做其他的更有价值事情，敲一些业务价值更大的代码。

这个是需要去权衡的，一个重要的衡量标准就是前面说的：投入产出比。

关于“不是所有的问题都必须被解决的，也可以选择绕过问题”这个事情，我再给你举一个我遇到的真实的例子。

几年前，我们团队遇到一个问题，我们使用的 RPC 框架是 Dubbo，有几个核心服务在投产期间滚动发布的时候，流量老是弄不干净，导致服务已经下线了，上游系统还在调用。

当时安排我去调研一下解决方案。

其实这就是一个优雅下线的问题，但是当时资历尚浅，我认真研究了一段时间，确实没研究出问题的根本解决方案。

后来我们给出的解决方案就是做一个容错机制，如果投产期间有因为流量不干净的问题导致请求处理失败的，我们把这些数据记录下来，然后等到投产完成后再进行重发。

没有解决根本问题，选择绕过了问题，但是从最终结果上看，问题是被解决了。

再后来，我们搭建了双中心。投产之前，A，B 中心都有流量，每次投产的时候，先把所有流量从 A 中心切到 B 中心去，在 A 中心没有任何流量的情况下，进行服务投产。B 中心反之。

这样，从投产流程上就规避了“流量老是弄不干净”的问题，因为投产的时候对应的服务已经没有在途流量了，不需要考虑优雅的问题了，从而规避了优雅下线的问题。

问题还是没有被解决，但是问题被彻底绕过。

最后，再举一个我在知乎上看到的一个回答，和我想要表达的观点，有异曲同工之妙：

http://www.zhihu.com/question/63…

这个回答下面的评论也很有意思，有兴趣的可以去翻一下，我截取两个我觉得有意思的：

在职场上，甚至在生活中，一个虽然没有解决方案但是可以被绕过的问题，我认为不是问题。

但是这个也得分情况，不是所有问题都能绕开的，假如是一个关键服务，那肯定不能置之不理，硬着头皮也得上。

关键是，我在职场上和生活中遇到过好多人，遇到问题的时候，似乎只会硬着头皮往上冲。

只会硬着头皮往上冲和知道什么时候应该硬着头皮往上冲，是两种截然不同的职场阶段。

所以有时候，遇到问题的时候，不要硬上，也让头皮休息一下，看看能不能绕过去。

欢迎来到 Jax 的专栏「Web 玩转文件操作」，快来了解 Web 端关于文件操作的方方面面！

转载请联系作者 Jax。

先来玩玩这个 Demo —— 一个网页端的本地文件管理器。

在上面的 Demo 中，点击「打开文件夹」按钮后，你可以选择电脑本地的某个文件夹来打开。然后就能对其中的文件做各种操作了，包括新建、右键打开、编辑、删除等等。你会发现，在网页上的操作会立刻在本地文件上实际生效。

如果你感觉是：”哟？有点儿意思！“，那么这篇文章就是专门为你而写的，读下去吧。

正所谓「边牧是边牧、狗是狗」，Web 应用早已不是当初的简陋网页了，它进化出了令人眼花缭乱的新能力，同时也在迅速追齐系统原生能力。如 Demo 所示，我们甚至可以把文件管理系统搬进网页，并且简单的 JavaScript 代码就能实现。Web 应用能有这样的威力，得益于浏览器对文件系统 API 的实现。

文件系统（File System Access）API 目前还处于社区草稿状态，但早在 2016 年，WHATWG 社区就已经开始着手设计这一标准，并且八年来一直在持续不断地打磨，迄今已经被各大主流浏览器所实现。

这套 API 足够简单易用，你很快就能掌握它，并且让它成为你的得力助手。但由于涉及到文件管理这个课题，它有很多方面都可以挖掘得很深很深，比如读写流、OPFS、安全策略等等。咱们这个专栏本着少吃多餐的原则，不会一次性囊括那么多内容。咱们的这第一铲，就先浅浅地挖一个「憨豆」 —— FileSystemHandle。

FileSystemHandle

在文件系统中，文件和文件夹是一个个实体，是所有状态和交互的核心。相对应地，在文件系统 API 中，我们用「FileSystemHandle」这个对象来对实体进行抽象。为了能够简洁地描述，我们在下文中将称之为「憨豆」。我们用对象属性来保存实体的名称、类型，通过执行对象方法来操作实体。

那么 FileSystemHandle 从何而来呢？一般是从用户操作而来。以文件为例，当用户通过文件窗口选择了某个本地文件之后，我们就能从代码层面获取到通向这个文件的入口，从而可以对文件进行管理操作。除此之外，拖拽文件进入也能得到憨豆

属性：name 和 kind

name：无论是文件还是文件夹，必然都有一个名字。

kind：实体的类型，值为 ‘file’ 代表文件；值为 ‘directory’ 代表文件夹。

校验方法 isSameEntry()

用于判断两个憨豆是否代表相同的实体。例如用户上传图片时，先后两次选择的是同一张图片，那么两个憨豆指向的其实是同一个文件。

const [handle1] = await showOpenFilePicker() // 第一次上传

const [handle2] = await showOpenFilePicker() // 第二次选择了同一个文件



const isSame = await handle1.isSameEntry(handle2)

console.log(isSame) // true

该方法也同样适用于文件夹校验。

我们可以借此来检测重复性。

删除方法 remove()

用于删除实体。比如，执行下列代码会现场抽取一个幸运文件来删除：

const [handle] = await showOpenFilePicker()

handle.remove()

但如果我们想要选中文件夹来删除，像上面那样直接调用是会报错并删除失败的。我们需要额外传入配置参数：

handle.remove({ recursive: true })

传参后的删除，是对文件夹里面的嵌套结构进行递归删除，这个设计理念旨在让开发者和用户在删除前知悉操作后果。

权限方法 queryPermission() 和 requestPermission()

用于向用户查询和获取读写权限，可以传入一个参数对象来细分权限类型。

const permission = await handle.queryPermission({ mode: 'read' }) // mode 的值还可以是 readwrite

console.log(permission)// 若值为 'granted'，则代表有足够权限

我们在对实体进行操作前，最好总是先查询权限。因此一个最佳实践是把这两个方法封装进通用操作逻辑中。

其他特性

除此之外，FileSystemHandle 还具有一些其他特性，比如可以转化为 indexDB 实例、可以通过 postMessage 传输到 Web Workers 里进行操作等等。我们会在后续的专栏文章中继续顺藤摸瓜地了解它们。

两个子类

到目前为止，FileSystemHandle 所具有的属性和方法都在上面了。你可能也意识到了，单靠这三招两式是不可能实现像 Demo 里那么丰富完备的文件操作的。

没错，这个憨豆只是一个抽象父类，它还有两个子类 FileSystemFileHandle、FileSystemDirectoryHandle，这两位才是文件和文件夹实体的真正代言人。对实体的常规操作，几乎都是通过这两个紫憨豆来执行的。

除了从父类继承而来的基因，两个紫憨豆都各自具有独特的属性和方法，满足了开发者对文件和文件夹两种不同实体的不同操作需求。

FileSystemFileHandle

在本专栏的上一篇文章《绕过中间商，不用 input 标签也能搞定文件选择》中，我们曾与文件憨豆有过一面之缘。那时候，我们通过 showOpenFilePicker 获取了文件憨豆，并调用它的 getFile 方法拿到了 文件 Blob。

此外，文件憨豆还具有的方法如下：

• createSyncAccessHandle()：用于同步读写文件，但是仅限于在 Web Workers 中。


• createWritable：创建一个写入流对象，用于向文件写入数据。

FileSystemDirectoryHandle

文件夹憨豆的特有方法如下：

• getDirectoryHandle()：按名称查找子文件夹。


• getFileHandle()：按名称查找子文件。


• removeEntry()：按名称移除子实体。


• resovle()：返回指向子实体的路径。

经过上述罗列，我们对两种憨豆的能力有了一个大概的印象。下面，我们将回到 Demo 的交互场景，从具体操作上手，看看文件系统 API 是如何在 JavaScript 中落地的。

操作 & 用法

载入文件夹

我们首先需要载入一个文件夹，然后才能对其中的子实体进行操作。

如果你碰巧读过上一篇文章，知道如何用 showOpenFilePicker() 选择文件，那你一定能举一反三推断出，选择文件夹的方法是 showDirectoryPicker()：

const dirHandle = await showDirectoryPicker()

showDirectoryPicker 方法也接收一些参数，其中 id、startIn 这两个参数与 showOpenFilePicker 方法 的同名参数完全对应。另外还支持一个参数 mode ，其值可以是 read 或 readwrite，用于指定所需的权限。

用户选择文件夹后得到的 dirHandle，就是一个 FileSystemDirectoryHandle 格式的对象。我们可以遍历出它的子实体：

for await (const sub of dirHandle.values()) {

  const { name, kind } = sub

  console.log(name, kind)

}

从子实体中取出名称和类别属性值，就可以对文件夹内容一目了然了。

读取文件内容

在上一步中，我们已经读取到了子实体的名字和类型，那么对于文件类型，我们可以先按名称检索到对应的憨豆：

// if sub.kind === 'file'

const fileHandle = await dirHandle.getFileHandle(sub.name)

再从文件憨豆中掏出文件 Blob，进一步读取到文件的内容：

const file = await fileHandle.getFile()

const content = file.text()

如果你用来调试的文件是文本内容的文件，那么打印 content 的值，你就可以看到内容文本了。

同理，获取子文件夹的方式是 dirHandle.getDirectoryHandle(sub.name)。

新建文件、文件夹

除了指定名称参数，getFileHandle 和 getDirectoryHandle 这两个方法还支持第二个参数，是一个一个配置对象 { create: true/false }，用于应对指定名称的实体不存在的情况。

例如，我们对一个文件夹实体执行 dirHandle.getFileHandle('fileA')，但该文件夹中并没有名为 fileA 的文件。此时第二个参数为空，等同于 create 的默认值为 false，那么此时会抛出一个 NotFoundError 错误，提示我们文件不存在。

而如果我们这样执行：dirHandle.getFileHandle('fileA', { create: true })，那么就会在当前文件夹中新建一个名为 fileA 的空文件。

同理，我们也可以用 dirHandle.getDirectoryHandle('dirA', { create: true }) 新建一个名为 dirA 的空文件夹。

在 Demo 中，我们实现了让用户在新建文件时自定义文件名，这其实是使用了 prompt 方法：

const fileName = prompt('请输入文件名')

await dirHandle.getFileHandle(fileName, { create: true })

在当下这个 AI 时代，Prompt 更多是以「LLM 提示词」被大家初识。在更早时候，它是浏览器实现的一个组件。其实这两种形态的含义是一致的，都是在人机交互中，从一端到另一端的输入输出流程。

编辑文件内容

刚刚我们读取了文件的内容，现在我们来对文件内容进行修改，然后再存回去。

我们已经能够通过 getFile() 方法拿到文本内容，那应该把内容放到哪里进行编辑呢？你有很多种选择：富文本编辑器、给 div 设置 contenteditable、唤起 VS Code…… 但本着最（能）小（用）原（就）则（行），我们还有更便捷的选项 —— prompt！

prompt() 方法也支持第二个参数，我们把文本内容传入，弹出弹窗后，你就会看到内容已经填在了输入框中，现在就可以随意编辑里面的字符了。

const file = await fileHandle.getFile()

const fileContent = await file.text()

const newContent = prompt('', fileContent) // newContent 即为修改后的文件内容

但是点击 Prompt 的确认按钮并不会让新内容自动写入文件，这里就需要用到上面提到的 createWritable 了。下面是一个完整的写入流流程：

const writable = await fileHandle.createWritable() // 对待修改文件开启写入流

await writable.write(newContent) // 把新内容写入到文件

await writable.close() // 关闭写入流

至此，新的内容就已经被保存到文件中了。你可以在 Demo 中再次右键、打开文件查看内容，你会发现确实读取到了修改后的内容。

文件重命名

修改文件名也是文件管理中的常规操作，文件系统 API 也提供了对应的方法来实现。可能手快的同学已经在尝试 fileHandle.rename() 方法了。但 API 中还真没有这个方法，我们其实是要用一个 move() 方法。惊不惊喜意不意外？

因为从底层视角看，重命名文件和移动文件的处理过程类型，都是需要先新建一个文件（使用新的命名或者放到新的位置），再把源文件的数据复制过去，最后把源文件删除。目前在 Web 端还没有更高效的处理方式。

我们只需从 Prompt 获取新名称，再传给 move() 方法即可：

const newName = prompt('请输入新的文件名')

await fileHandle.move(newName)

这样，文件重命名就搞定了。

删除文件、文件夹

删除实体就没有那么多幺蛾子了，我们甚至不用对文件和文件夹做逻辑上的区分，简单直接地调用 currentHandle.remove({ recursive: true }) 就行了。

但越是方便，就越要谨慎，因为涉及到删除用户的文件，所以如果要用于生产环境，最好给用户提供二次确认的机会。

写在结尾

恭喜你读完了本文，你真棒！

这次我们通过实现一个 Web 版文件管理器 demo，对文件管理 API 进行了较为深入的理解和实践。我再嘱咐两句：

我是 Jax，在畅游 Web 技术领域的第 7 年，我仍然是坚定不移的 JavaScript 迷弟，Web 开发带给我太多乐趣。如果你也喜欢 Web 技术，或者想讨论本文内容，欢迎来聊！你可以通过下列方式找到我：

掘金：juejin.cn/user/113435…

GitHub：github.com/JaxNext

微信：JaxNext

大家好，我是双越老师，wangEditor 作者。

我正在开发一个 Nodejs 全栈 AIGC 知识库项目 划水AI，包括富文本编辑器，多人协同编辑，AI 写作，AI 处理文本等。有兴趣的同学可以围观项目。

开始

虽然标题是 35 岁，但其实本文 2024 年我 36 岁时写的。36 岁总结 35 岁，也没毛病。

35 岁对于我们程序员来说是一个非常敏感的年龄，但我已过 35 ，看看往后会越来越敏感，还是越来越麻木？

本文和大家分享一下我个人在业余生活中的，我觉得很有意义的事情。甚至我觉得这些是事情的意义，都大于工作的成绩。

生活是一个整体，工作只是其中一部分，只是我们养家糊口的一个手段。工作以外的其他部分应该更加重要，例如业余爱好、饮食、休息、娱乐、家庭等。

1. 戒烟

我从大学毕业开始学着吸烟，到 35 岁已经有十几年的烟龄了。虽然每天吸烟量不大，但也断不了，有瘾。

我为什么要戒烟呢？

是觉得吸烟有害健康？—— 对，吸烟肯定有害健康，但人类天生是一种及时行乐的动物，谁会在乎 20 年 30 年以后的健康呢？人类天生是一个心存侥幸的动物（赌徒性质），也不是每个吸烟者都会有 xxx 病，对吧？之前看过一个段子，说某呼吸外科医生做完，累几个小时做完一台手术，先出去吸烟休息一下。

我戒烟，单纯就是想戒。我想摆脱烟草和尼古丁的控制，而且是想了很久了，不是一时突发奇想，之前就有充分的心理准备。

还有，我想在 35+ 的年纪做一点叛逆的事情，叛逆使人年轻，叛逆使人保持活力。年轻时吸烟是叛逆，年龄大了戒烟就是叛逆。年轻时叛逆是狂，年龄大了叛逆是帅。所以，各位大龄程序员，有机会要让自己叛逆起来，做一点帅的事情。

最后，当时 2023 年夏天，我正好不忙，天天闲着，总得找点事儿干。既然工作上不忙，那就在自己身上找点有意义事情做吧 —— 外求不得而向内求，如果没法从外面挣取，那就去提高自身。

烟瘾是什么？就是尼古丁的戒断反应，没有其他理由，没人其他任何事情会让你 1-2 小时就想一次，而且持续想。

关于烟草的本质，烟草的历史，烟草的商业化推广过程，烟草的洗脑广告…… 还有很多内容可以讲，本文就不展开了，有兴趣的可以留言咨询。我很早之前就看过，去学习这些，并且接受这些，才能更好的帮助戒烟。

所以，就这么戒了，到写作本文的时候，正好是戒了一年。我觉得这是我去年做过的最有价值的事情，比我工作挣的钱都有价值。

2. 戒酒

之前我是比较喜欢喝酒的，喜欢一帮人聚餐那种兴奋的状态。但后来喝多了就肚子难受，一躺下就想吐，于是决定不喝了。

有些人说：你可以少喝点。但在中国北方的酒桌上，只有 0 和 1 ，没有中间态。只要你喝了，一开始朋友劝你多喝点，再喝多一点就不用别人劝了，自己就开始主动找酒瓶子了。

我不懂酒，没喝过啥好酒，很少喝红酒。就日常喝的白酒和啤酒而言，我觉得都不好喝。

白酒，度数高，辣（尤其酱味的），容易醉。全世界就中国及其周边人喝白酒，国内几千的白酒没有国际市场。而且单就中国而言，白酒蒸馏技术几百年了，也只有最近这不到 100 年喝白酒。《红楼梦》上层人不喝白酒，《孔乙己》下层人也不喝白酒。

现在喝白酒的人，有两类：1. 被酒桌文化感染而顺从的人； 2. 有酒瘾想快速体验酒精的人。

啤酒，要分好多种，咱日常喝的瓶装的、桶装的，都可以统称为工业啤酒，像水一样，轻薄寡淡 —— 但它有酒精啊！

那种全麦啤酒（忘记名字了，不常喝）还是很好喝的，但价格较高，自己买点喝还行，聚餐喝那个太贵了（普通饭店也没有卖的），很少喝。

我身边也有一些朋友，每周都喝好几次，大部分是为了工作，拉拢客户关系。我觉得我还是比较幸运的，写写代码，改改 bug ，也不用太考虑人际关系。程序员的为数不多的好处。

3. 不看和自己无关的事情

我从不刷抖音（虽然我会发布一些抖音视频），但我之前很喜欢看今日头条 app ，每天闲了就刷一下，吃饭也看，睡前也看。

但是我都看了些啥呢？有一些是娱乐性的小视频，搞笑的，猎奇的，做饭吃饭的，我觉得这些很好，提供情绪价值。

其他的，什么俄 x 战争，什么国外 xxx 冲突，什么体育明星谁比谁厉害，什么传统武术，什么中医 …… 还有这些的评论，各路网友互怼。有时候看的都让人很带情绪，感觉有些人是不是傻，这么简单的道理看不明白？有些人是不是坏，不看事实，只看立场？

这些不仅不能提供情绪价值，反而会增加你的负面情绪。而且，根据《乌合之众》大众心理学研究，你只要参与了其中，你参与了互怼，你就会成为他们其中的一员，也变成傻子或坏人。围观，也是一种参与，你的心里会支持某一方。

更关键的是，这些事情我自己有关系吗？或者我的表态能决定这件事儿的走向吗？哪怕投一票决定一点点呢 —— 答案是显然的，要么没有任何关系，要么自己瞎操心。

所以，我卸载了今日头条 app ，不看了，眼不见心不烦，这些事情我不知道，也不影响我个人工作生活。从此以后，我觉得我的世界瞬间清净了，至少不会被那些负面情绪所打扰。

另外，我睡前也不看手机了，把手机扔在书房充电，直接睡觉。如果偶尔失眠或想事情，那就想，也不用非得拿着手机想，对吧。

总结

35 岁是一个里程碑和转折点，工作上如此，生活中也是如此。程序员是一个相对来说比较“单纯”的群体，我觉得更应该关注个人生活中的成长，共勉，加油～

前言

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

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

鸣谢：

在这个技术日新月异的时代，编程语言的更新换代似乎已经成为了家常便饭。但国产语言却一直不温不火，对于程序员来说，拥有一款属于我们自己的语言，一直是大家梦寐以求的事情。

如果我说有一种国产编程语言，它的运行速度比Rust快9倍，比GO快35倍，你会相信吗？

这不是天方夜谭，最近，被称为“国产编程语引领者”的MoonBit（月兔），宣布正式进入Beta预览版本阶段啦！

一听月兔这名字起得挺中式的。

一、初识MoonBit

MoonBit是由粤港澳大湾区数字经济研究院（福田）研发的全新编程语言。

① 官网

http://www.moonbitlang.cn/

② 目前状态

MoonBit是2022年推出的国产编程语言，并在2023年8月18日海外发布后，立即获得国际技术社区的广泛关注。

经过一年多的高速迭代，MoonBit推出了beta预览版。

MoonBit 目前处于 Beta-Preview 阶段。官方希望能在 2024/11/22 达到 Beta 阶段，2025年内达到 1.0 阶段。

③ 由来

诞生于AI浪潮，没有历史包袱：MoonBit 诞生于 ChatGPT 出世之后，使得 MoonBit 团队有更好的机会去重新构想整个程序语言工具链该如何与 AI 友好的协作，不用承担太多的历史包袱

二、MoonBit 语言优势

① 编译与运行速度快

MoonBit在编译速度和运行时性能上表现出色，其编译626个包仅需1.06秒，比Rust快了近9倍；运行速度比GO快35倍！

② 代码体积小

MoonBit 在输出 Wasm 代码体积上相较于传统语言有显著优势。

一个简单的HTTP 服务器时，MoonBit 的输出文件大小仅为 27KB，而 WasmCloud提供的http-hello-world 模板中 Rust 的输出为 100KB，TypeScript 为 8.7MB，Python 更是高达 17MB。

③ 多重安全保障

MoonBit 采用了强大的类型系统，并内置静态检测工具，在编译期检查类型错误，

MoonBit自身的静态控制流分析能在编译器捕获异常的类型，从而提高代码的正确性和可靠性。

④ 高效迭代器

MoonBit创新地使用了零开销的迭代器设计，使得用户能够写出既优雅又高效的代码。

⑤ 创新的泛型系统设计

MoonBit语言在它的测试版里就已经搞定了泛型和特殊的多态性，而且在编译速度特别快的同时，还能做到用泛型时不增加额外负担。

你要知道，这种本事在很多流行的编程语言里，都是正式发布很久之后才慢慢有的，但MoonBit一开始就做到了。这种设计在现在编程语言越来越复杂的大背景下特别关键，因为一个好的类型系统对于整个编程语言生态的健康成长是特别重要的。

三、应用场景

① 云计算

② 边缘计算

③ AI 以及教学领域的发展

四、开发样例

我们在官网 http://www.moonbitlang.cn/gallery/ 可以看到用使用MoonBit 开发的游戏样例

• 罗斯方块游戏


• 马里奥游戏


• 数独求解器


• 贪吃蛇游戏

五、语言学习

5.1 语法文档

如果你也对MoonBit感兴趣，想学习它，访问官方文档docs.moonbitlang.cn/。文档算是比较详细的了

5.2 在线编译器

无需本地安装编译器即可使用，官方提供了在线编译器

① 在线编辑器地址

try.moonbitlang.cn/

② 点击这儿运行代码

5.3 VS Code 中安装插件编写代码、

① 安装插件

② 下载程序

按下shift+cmd+p快捷键（mac快捷键，windows和linux快捷键是ctrl+shift+p），输入 MoonBit:install latest moonbit toolchain，随后会出现提示框，点击“yes”，等待程序下载完成。

③ 创建并打开新项目

下载完成后，点击terminal，输入moon new hello && code hello以创建并打开新项目。

④ 始执行代码

项目启动后，再次打开terminal，输入moon run main命令，即可开始执行代码。

六、小结

下面是晓凡的一些个人看法

MoonBit 作为一款新兴的国产编程语言，其在性能和安全性方面的表现令人印象深刻。

特别是它在编译速度和运行效率上的优化，对于需要处理大量数据和高并发请求的现代应用来说，是一个很大的优势。

同时，它的设计理念符合当前软件开发的趋势，比如对云计算和边缘计算的支持，以及对 AI 应用的适配。

此外，MoonBit 团队在语言设计上的前瞻性思考，比如泛型系统的实现，显示出了其对未来编程语言发展趋势的深刻理解。

而且，提供的游戏开发样例不仅展示了 MoonBit 的实用性，也降低了初学者的学习门槛。

大家好，我是晓凡。

写在前面

不知道大家有没有做财务的朋友，我就有这么一位朋友就经常跟我抱怨。一到月底简直就是噩梦，总有加不完的班，熬不完的夜，做不完的报表。

一听到这儿，这不就一活生生的一个“大表哥”么，这加班跟我们程序员有得一拼了，忍不住邪恶一笑，心里平衡了很多。

身为牛马，大家都不容易啊。我不羡慕你数钱数到手抽筋，你也别羡慕我整天写CRUD 写到手起老茧🤣

吐槽归吐槽，饭还得吃，工作还得继续干。于是乎，真好赶上周末，花了一天的时间，帮朋友写了个小工具

一、功能需求

跟朋友吹了半天牛，终于把需求确定下来了。就一个很简单的功能，通过名字，将表一和表二中相同名字的金额合计。

具体数据整合如下图所示

虽然一个非常简单的功能，但如果不借助工具，数据太多，人工来核对，整合数据，还是需要非常消耗时间和体力的。

怪不得，这朋友到月底就消失了，原来时间都耗在这上面了。

二、技术选型

由于需求比较简单，只有excel导入导出，数据整合功能。不涉及数据库相关操作。

综合考虑之后选择了

• PowerBuilder


• Pbidea.dll

使用PowerBuilder开发桌面应用，虽然界面丑一点，但是开发效率挺高，简单拖拖拽拽就能完成界面（对于前端技术不熟的小伙伴很友好）

其次，由于不需要数据库，放弃web开发应用，又省去了云服务器费用。最终只需要打包成exe文件即可跑起来

Pbidea.dll 算是Powerbuilder最强辅助开发，没有之一。算是PBer们的福音吧

三、简单界面布局

四、核心代码

① 导入excel

​

string ls_pathName,ls_FileName //路径+文件名，文件名

long ll_Net

long rows

dw_1.reset()

uo_datawindowex dw

dw = create uo_datawindowex

dw_1.setredraw(false)

ll_Net = GetFileSaveName("请选择文件",ls_pathName,ls_FileName,"xlsx","Excel文(*.xlsx),*.xlsx")

​

rows = dw.ImportExcelSheet(dw_1,ls_pathName,1,0,0)

destroy dw

dw_1.setredraw(true)

MessageBox("提示信息","导入成功 " + string(rows) + "行数据")

​