1.安利一款超级好用的源码文本编辑器Typora（仅供学习）
2.Windows95应用模拟器改Windows 3.2步骤详解
3.Electron-托盘、气泡(闪烁)消息、源码只启动一个实例、源码Win/Mac打包配置、源码最小化/退出等小结
4.StarUml下载，源码安装和授权破解教程
5.Microsoft visual c++弹窗？
6.Windows未成功关闭。源码seo查询系统源码如果这是源码由于系统无响应，或者是源码为保护数据而关闭系统...这怎么办？

安利一款超级好用的文本编辑器Typora（仅供学习）

       我们在编程过程中，常常会使用各种文本编辑器来提高工作效率。源码一款出色的源码编辑器能让我们更快地完成和优化代码。接下来，源码我要向大家介绍一款名为Typora的源码文本编辑器。

       1、源码什么是源码Typora

       Typora是由Abner Lee开发的一款轻量级Markdown编辑器。与其他编辑器不同，源码Typora采用所见即所得的编辑方式，实现了即时预览的功能，同时也支持源代码编辑模式。使用Typora，我们可以轻松地创建格式化的文档，编写清晰、美观的文本，并支持标题、列表、表格、脚注等多种格式。

       2、Typora的优点

       Typora是一款强大的跨平台Markdown编辑器，具有以下特点：

       1）实时预览：支持实时预览Markdown文档，即时查看编辑后的效果。

       2）简洁易用：界面简洁清晰，操作简单直观，适合Markdown初学者和专业用户使用。

       3）支持多种导出格式：可以将Markdown文档导出为PDF、HTML、Word等多种格式。

       4）自定义样式：支持自定义主题和样式，用户可以根据个人喜好定制编辑界面。

       5）全平台支持：支持Windows、Mac和Linux系统，用户可以在不同平台上无缝使用Typora编辑Markdown文档。

       3、如何安装Typora

       方法1：访问Typora官方中文站下载。

       方法2：[百度网盘] pan.baidu.com/s/1kkrrt2... 提取码：6mcs

       需要注意的是，Typora是收费软件。下面我将提供激活教程。

       4、如何激活Typora

       1）打开网盘下载的文件，右键安装typora（如果在官网下载的，请忽略这步）

       2）复制app.asar文件到Typora安装路径下的resources文件夹，替换掉原先的文件。

       3）打开Typora，输入你的邮箱和序列号（序列号在文件夹中的序列号.txt），即可激活。

       4）成功激活后即可使用Typora。

       5、如何使用Typora

       安装完成后，打开Typora。在开始编写之前，你需要创建一个新的Markdown文档或打开一个已存在的文档。点击菜单栏中的“文件”，选择“新建”或“打开”，即可创建或打开一个文档。

       创建或打开文档后，你可以开始编写Markdown文本。在编写过程中，Typora会自动实时预览你的文档，让你随时查看文档的最终效果。

       完成编写后，你可以选择保存文档。点击菜单栏中的“文件”，选择“保存”或“另存为”，将文档保存到你想要的位置。

       6、Typora的缺点

       1）不支持实时协作，需要使用其他工具进行多人协作编辑Markdown文档。

       2）不支持插件扩展，需要使用其他插件或工具来添加特定功能。

       3）需要付费购买高级功能，使用一些高级功能需要支付一定的费用。

       总的来说，尽管Typora存在一些缺点，但它仍然是一款非常优秀的Markdown编辑器，提供了许多实用的neumf源码解析功能和特性，可以让我们更方便地编辑和排版Markdown文本。

Windows应用模拟器改Windows 3.2步骤详解

       8月日消息，国外有人搞了一个Windows应用模拟器，下下来玩了一下，以为连里面系统都是js写的，顿时感觉挺厉害，后来感觉太逼真了。。。不像是js实现的，就看了一下源码，发现本质上是一个js写的类似qemu的玩意，跑了一个windows 镜像。于是，我改成了跑Windows 3.2。

       下面分享一下我的修改过程。

       准备工具：

       Windows 的Linux子系统。(用来装npm，用node.js for windows理论可行，但我没有试过)

       压缩软件，推荐是7z。

       步骤：

       准备一个raw(img)格式的系统镜像，改名为windows.img

       镜像，你可以像我一样自己做一个镜像，也可以找现成的，不过建议选择对系统要求比较低的系统镜像，以降低出错的概率。

       我们打开Linux子系统，输入sudo apt install npm，如果你是fedora opensuse之类的请输入别的包管理命令。

       然后输入sudo npm -g install asar，安装asar

       如果你没运行过模拟器，请先运行一次，以便主程序解压压缩包。

       在Linux子系统中定位到模拟器的安装文件夹(右键点击win快捷方式，第二个选项卡里点击查找目标)，再定位到app-1.1.0\resources，输入asar extract app.asar dest

       我们把镜像放到解压之后的src\renderer\images中，覆盖原有文件，原来里面的那个state.bin需要删除，不然容易出错。

       删除原来的app.asar，然后在终端中输入asar pack dest app.asar。

       别急!你还需要下面的步骤。

       由于已经运行过模拟器了，所以它会在C:\Users\用户名\AppData\Roaming中生成一个叫windows的文件夹的缓存，所以我们需要删掉这个文件夹。

       好了，步骤结束，运行模拟器，但请点击Discard State Boot From Scratch，而不是Starting Windows (这一点很重要!)。因为的state.bin已经删除，再运行第一个就有可能出错。

Electron-托盘、气泡(闪烁)消息、只启动一个实例、Win/Mac打包配置、最小化/退出等小结

       在Electron开发过程中，我接触并实践了一系列相关的工具和技术，如Vue、Vuex、Element、Axios和Cordova等。在接触Flutter时，我也在思考它是否能成为一种趋势。在Visual Studio Code的背景设置代码方面，我了解了一些基本的配置。目前，项目已经进入了打包测试阶段，尤其是在Mac打包过程中，我遇到了一些问题。以下内容是基于个人经验进行的总结，可能存在认识上的浅薄，但希望能为初学者提供一些实用的指导。

       在应用图标、安装界面图标、托盘图标和资源的配置与使用中，通常会将这些资源放在`build/`目录下的`icons`文件夹中，如`x.png`和`icon.png`。这些资源通常用于主进程，即浏览器外壳。同时，发卡源码系统`static`文件夹下可以存放页面中用到的资源，这些资源会被打包到安装包或可执行程序目录下的`app.asar`压缩包中。`static`资源更多地用于渲染进程页面相关，而`build/xxxx`目录则用于程序级别的资源。

       打包过程中，Electron默认不会将`icons`资源打包，需要通过`package.json`的`extraResources`配置来实现。在Windows打包后，资源会被放置在`win-unpacked/resources`目录下；而在Mac打包后，资源路径则较为复杂，通常在`dmg`或`zip`安装程序内。对于Windows，可以使用`nsis`来配置安装程序信息，如创建快捷方式、安装程序图标、卸载程序图标等。

       在打包后的安装包中，可以配置英文版，优化程序的图标，并对`package.json`进行相关修改以适应不同平台需求。例如，针对Win和Mac资源路径的不同，可以使用`path.join`方法来确保资源路径的正确性。托盘图标采用PNG格式，并针对不同平台进行适配，以解决路径匹配问题。

       在创建托盘和实现气泡闪烁功能时，需要使用定时器来回切换图标，透明图标可以达到闪烁效果。在实现只启动一个实例、点击关闭按钮最小化到托盘、点击托盘弹出程序界面等功能时，代码逻辑需要根据平台（如Win和Mac）进行区分处理。

       对于Websocket接收推送消息并实现气泡闪烁及消息通知处理，需要在Vue中封装相应的方法。初始化socket并注册回调，以接收推送消息，然后通过`ipcRenderer`将消息发送给主进程，主进程进行消息通知处理。同时，需要考虑Win和Mac平台上的通知方式差异，如使用`appTray.displayBalloon`或`window.Notification`。

       在实现程序自动更新时，可以使用`electron-builder`配合`electron-updater`。首先需要配置更新服务器地址，然后在`src/main/index.js`中实现更新检查、弹窗、日志处理等功能。遇到的常见问题包括Electron版本过低导致的错误，可以通过升级Electron版本来解决。在打包和更新过程中，还需要解决资源路径配置问题，如富文本控件的路径配置。

       在Electron开发中，除了专注于前端界面制作和逻辑处理，还需关注跨平台开发、资源管理、打包配置等细节。同时，通过实践和学习，如深入Android源码和Flutter，可以进一步扩展跨平台开发能力。虽然Electron并非我的专业领域，但通过不断学习和实践，希望能为团队带来价值。

StarUml下载，安装和授权破解教程

       首先，你可以从官方网址获取StarUML：/microsoft/vscode $ git reset --hard bbcaf3db8bb8adf0ccfa

       我们可以使用 Code (lol) 来导航源代码。事实上，我已经在 WSL 中为这个漏洞创建了具有相同扩展名的概念验证。

       Visual Studio Code在 WSL 内以服务器模式运行，并与 Windows 上的代码示例对话（我称之为代码客户端）。这使我们可以在 WSL 中编辑文件和运行应用程序，而不需要运行其中的所有内容。

       远程开发架构

       可以通过 SSH 和容器在远程计算机上进行远程开发。GitHub Codespaces 使用相同的技术（很可能通过容器）。

       在 Windows 上使用它的方法：

       1.打开一个WSL终端示例，在Windows上的代码中应该可以看到远程WSL扩展；

       2.在 WSL 中运行code /path/to/something；

       3.如果未安装代码服务器或已过时，则会下载它；

       4.VS Code 在 Windows 上运行；

       5.你可能会收到一个 Windows 防火墙弹出窗口，用于执行如下所示的可执行文件：

       服务器的防火墙对话框

       这个防火墙对话框是我执行失败的原因。出现该对话框是因为 VS Code 服务器想要监控所有接口。

       从我信任的Process Monitor开始：

       1.运行进程监控器；

       2.在WSL中运行code .；

       3.Tools > Process Tree；

       4.我运行代码（例如，Windows Terminal.exe）的极速云源码终端示例中运行Add process and children to Include filte。

       Procmon 的进程树

       经过一番挖掘，我发现了 VSCODE_WSL_DEBUG_INFO 环境变量。我只是在 WSL 中将 export VSCODE_WSL_DEBUG_INFO=true 添加到 ~/.profile 。运行服务器后我们会得到额外的信息。

       VSCODE_WSL_DEBUG_INFO=true

       输出被清理。

       检查命令行参数。

       可以看到出现了WebSocket词汇。

       运行 Wir.shark 并捕获loopback接口上的流量。然后我再次在 WSL 中运行代码。这次可以看到两个 WebSocket 握手。

       在 Wireshark 中捕获的 WebSocket 连接

       该运行中的服务器端口是，我们也可以从日志中看到。在 Windows 上的代码客户端中打开命令面板 (ctrl+shift+p) 并运行 > Remote-WSL: Show Log。

       远程 WSL：显示日志

       最后一行有端口：在 mon/ipc.net.ts 中看到协议的源代码。

       来自服务器的第一条消息是 KeepAlive 消息。

       在协议定义中，我们可以看到不同的消息类型。

       在 /src/vs/platform/remote/common/remoteAgentConnection.ts 中，它在代码的其他部分被称为 OKMessage 和heartbeat。

       客户端在/src/vs/platform/remote/common/remoteAgentConnection.ts的connectToRemoteExtensionHostAgent中处理此问题。客户端(Windows上的代码)发送这个包，它是一个KeepAlive和一个单独的认证消息。

       最初，我认为长度字段是 个字节而不是 4 个字节，因为其余的字节总是空的。然后我意识到只有常规消息使用消息 ID 和 ACK 字段，而且我只看到了不规则的握手消息。

       在修复之前，没有勾选此选项。

       注意：在 -- 更新之前（commit bbcaf3db8bb8adf0ccfa）客户端没有发送数据。但是，使用此提交，我们仍然可以在没有此密钥的情况下发送消息并且它会起作用。这是我们给服务器签名的内容，以检查连接到正确的服务器。

       服务器响应一个签名请求。

       另一个 JSON 对象：

       服务器已经签名了我们在前一条消息中发送的数据，并用它自己的数据请求进行了响应。

       客户端验证签名的数据，以检查它是否是受支持的服务器。当创建我们的客户端时，可以简单地跳过。

       使用options.signService.validate 方法，然后就会得到/src/vs/platform/sign/node/signService.ts。

       vsda 是一个用 C++ 编写的 Node 原生插件，将 Node 原生插件视为共享库或 DLL。该插件位于 /microsoft/vsda 的私有存储库中，根据mit}/node_modules/vsda/build/Release/vsda.node。

       我找到了/kieferrm/vsda-example，并通过一些实验找到了如何使用它创建和签名消息。

       1.用msg1 = validator.createNewMessage("")创建一个新消息，输入至少4个字符。

       2.使用signed1 = signer.sign(msg1)进行签名。

       3.使用 validator.validate(signed1) 对其进行验证，响应为“ok”。

       需要注意的是，如果你创建了新消息，则无法再验证旧消息。在源代码中，每条消息都有自己的验证器。

       Linux 版本有符号，大小约为 KB。把它放到 IDA/Ghidra 中，应该就可以开始了。

       我花了一些时间，想出了这个伪代码。可能不太正确，但可以让你大致了解此签名的工作原理。

       1.用当前时间 + 2*(msg[0]) 初始化 srand，它只会创建 0 到 9（含）之间的随机数；

       2.从许可证数组中附加两个随机字符；

       3.从 salt 数组中附加一个随机字符；

       4.SHA；

       5.Base；

       6.；

       7.Profit。

       仅从许可证数组中选择前 个位置的字符，它总是 rand() % ，但salt 数组翻了一番。

       许可证数组的字符串如下所示：

       salt 数组的前 个字节（查找 Handshake::CHandshakeImpl::s_saltArray）是：

       我从来没有真正检查过我的分析是否正确，不过这无关紧要，知道如何使用插件签名消息，这就足够了。

       接下来，客户端需要签名来自服务器的数据并将其发送回来，以显示它是一个“合法”的代码客户端。

       服务器响应如下：

       客户端发送了如下消息：

       提交应该匹配服务器的提交哈希。这不是秘密。这可能是全屏html源码最后一个稳定版本提交（或最后几个之一）。这只是检查客户端和服务器是否在同一版本上。它也可以在 /parsiya/code-wsl-rce /parsiya/Parsia-Code/tree/master/code-wsl-rce

       模拟代码客户端

       创建客户端并使用协议连接到服务器的代码位于 VS Code GitHub 存储库中，这需要大量的复制/粘贴和解析，我只花了几个小时。

       如果要创建一个快速的概念验证，应该满足一些假设：

       1.找到本地的 WebSocket 端口；

       2.从外部连接到Node Inspector示例；

       查找本地 WebSocket 端口并不难，从浏览器扫描本地服务器并不是什么新鲜事。服务器也可以从外部使用，因此我们不受那里的浏览器约束。

       Chrome 限制不起作用，因为 WebSocket 服务器需要一个网络服务器来处理握手。我也很好奇 WebSocket 节流是 Chrome 特定的保护还是 Chromium 的一部分。

       有趣的是，Chrome 浏览器有一个保护机制，可以防止恶意行为者暴力破解 WebSocket 端口，它在第 次尝试后开始节流。不幸的是，这种保护很容易被绕过，因为扩展的 HTTP 和 WebSocket 服务器都在同一个端口上启动。这可用于通过向 img 标签添加 onload 处理程序来检查特定本地主机端口上的是否存在来强制所有可能的本地端口。

       也就是说，这是一个开发环境，用户可能整天都在 WSL 中开发并且从不关闭他们的浏览器选项卡，因此如果他们打开我们的网站，我们就有可能找到它。

       连接到Node Inspector示例是另一回事，我们无法从浏览器执行此操作，因此我们需要我们的服务器可以访问受害者的计算机。

       第二种利用方法（模拟代码客户端）没有这些限制，因为浏览器可以与本地服务器通信并执行所有操作。它只需要我们对协议进行逆向工程并找出要发送的正确消息。

       当你收到 WebSocket 升级请求时，请根据许可名单检查 Origin 标头。代码客户端在该标头中发送 vscode-file://vscode-app，以便我们可以使用它来操作。

       参考及来源：/blog/---rce-in-visual-studio-codes-remote-wsl-for-fun-and-negative-profit/

Windows未成功关闭。如果这是由于系统无响应，或者是为保护数据而关闭系统...这怎么办？

       这个故障你的描述不够详细，也没提供故障代码，所以建议你利用我总结的通用的系统修复方法尝试解决，具体如下：

先关机，然后打开主机箱，把硬盘的电源线和数据线拔下来，然后过2分钟再插上，重新开机试试。然后用下述方法修复系统：

开机不断点击F8键，进入系统操作选单（如果是Win8,Win8.1,Win系统，在看见开机画面后长按电源键关机，短时间内重复三次左右可以进入WinRE { Windows 恢复环境}，但有的用户可能需要直接断开电源。这样开机后应该能出现高级恢复的界面了，在高级回复界面，选择进入安全模式。

第一，由软：尝试修复操作系统：

1、如果有外接设备：如U盘、USB移动硬盘，或者读卡器里面有存储卡，请去除后再试

2、去除加装非标配部件，如内存、硬盘等，建议您联系操作者将添加的部件去除后再试

3、进入电脑BIOS并查看?BIOS中是否还能识别硬盘，同时选择“Load Optimal Defaults”或“Optimized Defaults”选项恢复BIOS默认设置后测试

4、开机不断点击F8键，进入系统操作选单（如果是Win8,Win8.1,Win系统，在看见开机画面后长按电源键关机，短时间内重复三次左右可以进入WinRE { Windows 恢复环境}，但有的用户可能需要直接断开电源。这样开机后应该能出现高级恢复的界面了），选“最后一次正确配置”，重启电脑，看能否解决。

       

5、开机不断点击F8键，进入系统操作选单（如果是Win8,Win8.1,Win系统，在看见开机画面后长按电源键关机，短时间内重复三次左右可以进入WinRE { Windows 恢复环境}，但有的用户可能需要直接断开电源。这样开机后应该能出现高级恢复的界面了），然后寻找“安全模式”，并进入“安全模式”，如能成功进入，依次单击“开始”→“所有程序”→“附件”→“系统工具”→“系统还原”，出现“系统还原对话框”，选择“恢复我的计算机到一个较早的时间”。 这样可以用Windows系统自带的系统还原功能，还原到以前能正常开机的时候一个还原点。（如果有的话）

6、用系统安装光盘或者系统安装U盘，放入光驱或者插入USB接口，重启电脑，进入光盘安装系统状态或者进入U盘安装系统状态，等到启动界面闪过后，不要选安装系统，而是选修复系统，对目前系统进行修复（可能会运行很长时间，2-4小时都可能），耐心等待修复完成，看看是否能解决问题。（本文结尾，详述了：U盘设置为第一启动顺位设备的方法）

7、不稳定的硬件设备，设备驱动程序过期，以及第三方程序干扰也会造成黑屏或者蓝屏，建议先进入安全模式，自行评是否原因为驱动程序过期或者三方程序干扰。此时，请您到电脑制造商网站上下载最近的BIOS, 声卡或显卡等所有可用驱动进行更新来解决问题。

 

如以上7个方法都无效，只能重装系统。

二、到硬：看看是否是硬件的问题：

1，主板钮扣电池没电了，这时保存时间等将在关机断电后，信息将无法保存。换一块新电池试一下。

2，主板BIOS出错，一些主板有防入侵机制。如果最近有跟换过配件，也可能是主板BIOS的错误引起。解决的办法是开机按DEL键（或者开机屏幕提示的键），进入主板BIOS，初始化BIOS设置信息，通常按F9可以恢复出厂默认设置，再按F保存退出重启电脑。

3，CMOS（BIOS）设置错误,主要是关于软件的设置的选项出现了问题。可以在开机后入Bios 进行设置。

这时可以查看一下自己的机器有没有软驱、光盘或其它附设[如:显卡]，如果没有这些硬件，而电脑却设置了这些，可以试着把这些选项关掉或设为Disabled.

[注:CD/DVD/CD-RW DRIVE：可读写的光驱 CD-ROW DEVICE：只读光驱 Diskette Drive：软盘驱动器 Floppy Floppy Device：软驱设备]

4，CMOS（BIOS）原来设置的部分与现在的硬件有冲突的部分.可以前将CMOS（BIOS）进行放电,在主板钮扣电池旁边有一个cmos 的三针跳线,而一般其中的两个针是联在一起的,这时可以在关机断电的情况下,将跳帽拔出,用跳帽将两个针联在一起进行放电[此过程一般4秒左右],而后再恢复到样子.或是将钮扣电池拔下,反过来装进去等待5-6秒左右进行放电,而后恢复到原来的样子，在开机后可以进入CMOS（BIOS）恢复其默认设置即可。

5，是否是未装显卡驱动，或者显卡驱动损坏，解决办法、；更新显卡驱动程序，用电脑自带的驱动程序光盘或者去显卡官网下载最新驱动程序，更新显卡驱动，也可以去驱动之家网站，下载驱动精灵最新版，升级显卡驱动； 

6，硬盘检测没有过去，可以试着给硬盘换下数据线，如果没有线也可以试着把数据线两头对换一下，再换个主板上的接口。 

7，如果硬盘换过数据线后还是无效，也可以先试着拔掉硬盘的数据线不接，然后开机测试。看是否还会卡在LOGO屏这里，如果能跨过LOGO界面，估计就是硬盘故障了，进入BIOS寻找硬盘或者进入PE系统检测硬盘健康度，如果硬盘读不到或者检测硬盘证明已经损坏，就只有更换硬盘了。

8，硬件接触不良 主要表现在显卡或内存条与主板接触不良。这时可以把显卡或者内存条拔掉，把显卡或者内存条拔掉不影响开机时进入cmos界面.这时如果进入这个界面时,没出CMOS（BIOS）setting wrong,就可以断定是显卡或者内存条的问题. 可以先用好一点的橡皮对其与主板接触的部分进行擦拭,内存也是用橡皮擦拭.

9，硬盘与光驱 不同内存条之间有冲突，此时可以进行逐一排查，可以先把光驱的电源线与数据排线拔掉，而后试着分别只用一条内存进行排查。

，检查机器是否有外接设备连接，U盘、移动硬盘等等外接设备可能插在电脑USB口上忘记拔掉了，造成主板自检卡主通过不了。解决的办法就是拔出多余的外接设备，再重启电脑。

，检查一下键盘和鼠标是否接反。这里指的是PS/2接口的键盘鼠标，很多人大意，把键盘和鼠标的接口插反了，造成开机电脑的自检错误以至于卡屏。解决的办法，先关机，重新接过键盘鼠标，通常紫色的接口为键盘，绿色接口为鼠标。 

，主板本身可能出了问题.可以先检查一下是否主板电池电路断路，或者是否有电容爆掉,如果是的话,自己焊接和更换或者找电脑维修商帮你焊接和更换一个同规格电容的即可。如果是主板坏了，那只有去买个新的换上啦。

，机箱不清洁.CPU风扇积灰太多不能正常运行,造成CPU温度过高，用毛刷、电吹风将机箱内壁、CPU风扇、显卡风扇、主板上的积灰都清理一遍。

基于Umi搭建Electron App——打包优化

       在基于Umi搭建Electron App的过程中，发现打包后的dist包体积过大，影响应用下载或更新的用户体验。本文将深入分析优化打包过程，从而减小最终生成的文件大小。首先，分析使用webpack+electron-builder打包后的文件构成，发现主要问题在于过大体积的安装程序和asar文件。具体分析如下：

       在简单工程中，通过对比electron-builder --dir和直接使用electron-builder命令的打包结果，发现两种方式在体积上的主要差异在于安装程序Setup.exe的大小，前者较后者减少了几个文件，体积缩小了MB。一个基本的electron工程的最终体积已达到MB，实际项目体积只会更多。

       分析打包文件目录结构时，注意到.exe文件实际是编译好的文件，主要功能是加载resources/app.asar中的内容。asar文件则对源代码进行基本加密，防止直接访问源代码。通过对比简单工程与复杂工程（集成umi、ant-design等dependencies）的打包结果，发现复杂工程体积显著增大，主要问题出现在asar文件的大小上。

       进一步优化路径在于将web应用和electron的package.json分离，利用electron-builder支持的双package.json结构。具体操作包括新建app文件夹、移动main.js至app文件夹、在app文件夹中新建package.json、添加相关配置、修改webpack打包配置和main.js内容以避免重复打包dependencies，同时调整electron-builder打包流程，以减少体积。

       优化后，基本Electron-Umi应用的.exe文件体积减少了MB，asar文件体积减少了.MB，整体dist包大小减小了MB。这不仅显著提升了应用的下载和更新体验，也为后续的开发提供了更优化的基础。

       优化后的代码和具体配置可以参考相关文档和仓库地址，以实现更高效和优化的Electron App构建流程。

app.asar是什么文件？

       在Electron应用程序的世界里，app.asar文件扮演着核心的角色。它是一种专门设计用于存储和打包应用程序主业务逻辑的特殊文件。与传统的文件不同，app.asar 文件采用了压缩技术，通过Electron的内置工具 asar pack 命令进行生成。这种压缩方式旨在优化应用的大小，提高加载速度和安全性，因为它对文件进行加密处理，使得源代码更难以直接访问，从而保护了应用的隐私和知识产权。因此，当你看到一个app.asar 文件时，它实际上是Electron应用的“心脏”，包含了运行应用所需的关键组件和数据。

抽丝剥茧：Electron与Node.js的奇葩Bug

       起因是最近在用Electron开发一个桌面端项目，有个需求是需要遍历某个文件夹下的所有JavaScript文件，对它进行AST词法语法分析，解析出元数据并写入到某个文件里。需求整体不复杂，只是细节有些麻烦，当我以为开发的差不多时，注意到一个匪夷所思的问题，查的我快怀疑人生。

       缘起

       什么问题呢？

       原来这个需求一开始仅是遍历当前文件夹下的文件，我的获取所有JS文件的代码是这样的：

       后来需求改为要包含文件夹的子文件夹，那就需要进行递归遍历。按照我以前的做法，当然是手撸一个递归，代码并不复杂，缺点是递归可能会导致堆栈溢出：

       但做为一个紧跟时代浪潮的开发者，我知道Node.js的fs.readdir API中加了一个参数recursive，表示可以进行递归，人家代码的鲁棒性肯定比我的好多了：

       只改了一行代码，美滋滋~

       兼容性怎么样呢？我们到Node.js的API文档里看下：

       是从v..0添加的，而我本地使用的Node.js版本正是这个（好巧），我们Electron中的Node.js版本是多少呢？先看到electron的版本是.0.4：

       在Electron的 发布页上能找到这个版本对应的是..1，比我本地的还要多一个小版本号：

       这里需要说明一下，Electron之所以优于WebView方案，是因为它内置了Chrome浏览器和Node.js，锁定了前端与后端的版本号，这样只要Chrome和Node.js本身的跨平台没有问题，理论上Electron在各个平台上都能获得统一的UI与功能体验。 而以Tauri为代表的WebView方案，则是不内置浏览器，应用程序使用宿主机的浏览器内核，开发包的体积大大减小，比如我做过的同样功能的一个项目，Electron版本有M+，而Tauri的只有4M左右。虽然体积可以这么小，又有Rust这个性能大杀器，但在实际工作中的技术选型上，想想各种浏览器与不同版本的兼容性，换我也不敢头铁地用啊！ 所以，尽管Electron有这样那样的缺点，仍是我们开发客户端的不二之选。 之所以提这个，是因为读者朋友需要明白实际项目运行的是Electron内部的Node.js，而我们本机的Node.js只负责启动Electron这个工程。

       以上只是为了说明，我这里使用fs.readdir这个API新特性是没有问题的。

       排查

       为方便排查，我将代码再度简化，提取一个单独的文件中，被Electron的Node.js端引用：

       能看到控制台打印的 Node.js 版本与我们刚才查到的是一样的，文件数量为2：

       同样的代码使用本机的Node.js执行：

       难道是这个小版本的锅？按理说不应该。但为了排除干扰，我将本机的Node.js也升级为..1：

       这下就有些懵逼了！

       追踪

       目前来看，锅应该是Electron的。那么第一思路是什么？是不是人家已经解决了啊？我要不要先升个级？

       没毛病。

       升级Electron

       将Electron的版本号换成最新版本v.1.0：

       再看效果：

       我去，正常了！

       不过，这个包的升级不能太草率，尤其正值发版前夕，所以还是先改代码吧，除了我上面手撸的代码外，还有个包readdirp也可以做同样的事情：

       这两种方式，在原版本的Electron下都没有问题。

       GitHub上搜索

       下来接着排查。

       Electron是不是有人发现了这个Bug，才进行的修复呢？

       去 GitHub issue里瞅一瞅：

       没有，已经关闭的问题都是年提的问题，而我们使用的Electron的版本是年月日发布的。 那么就去 代码提交记录里查下（GitHub这个功能还是很好用的）：

       符合条件的就一条，打开看下：

       修复的这个瞅着跟我们的递归没有什么关系嘛。

       等等，这个文件是什么鬼？

       心血来潮的收获

       我们找到这个文件，目录在lib下：

       从命名上看，这个文件是对Node.js的fs模块的一个包装。如果你对Electron有了解的话，仔细一思索，就能理解为什么会有这么个文件了。我们开发时，项目里会有许多的资源，Electron的Node.js端读取内置的文件，与正常Node.js无异，但事实上，当我们的项目打包为APP后，文件的路径与开发状态下完全不一样了。所以Electron针对打包后的文件处理，重写了fs的各个方法。

       这段代码中重写readdir的部分如下：

       上面的判断isAsar就是判断是否打包后的归档文件，来判断是否要经Electron特殊处理。如果要处理的话，会调用Electron内部的C++代码方法进行处理。

       我发现，这里Electron并没有对打包后的归档文件处理递归参数recursive，岂不是又一个Bug？应该提个issue提醒下。

       不过，我们目前的问题，并不是它造成的，因为现在是开发状态下，上面代码可以简化为：

       对Promise了如指掌的我怎么看这代码也不会有问题，只是心血来潮执行了一下：

       我去，差点儿脑溢血！

       好的一点是，曙光似乎就在眼前了！事实证明，心血来潮是有用的！

       Node.js的源码

       这时不能慌，本地切换Node.js版本为v，同样的代码再执行下：

       这说明Electron是被冤枉的，锅还是Node.js的！

       Node.js你这个浓眉大眼的，居然也有Bug！呃，还偷偷修复了！

       上面的情况，其实是说原生的fs.readdir有问题：

       也就是说，fs.promises.readdir并不是用util.promisify(fs.readdir)实现的！

       换成同步的代码readdirSync，效果也是一样：

       我们来到Node.js的GitHub地址，进行 搜索：

       打开这两个文件，能发现，二者确实是不同的实现，不是简单地使用util.promisify进行转换。

       fs.js

       我们先看 lib/fs.js。

       当recursive为true时，调用了一个readdirSyncRecursive函数，从这个命名上似乎可以看出有性能上的隐患。正常来说，这个函数是异步的，不应该调用同步的方法，如果文件数量过多，会把主进程占用，影响性能。

       如果没有recursive，则是原来的代码，我们看到binding readdir这个函数，凡是binding的代码，应该就是调用了C++的底层库，进行了一次『过桥』交互。

       我们接着看readdirSyncRecursive，它的命名果然没有毛病，binding readdir没有第4个参数，是完全同步的，这个风险是显而易见的：

       fs/promises.js

       在lib/internal/fs/promises.js中，我们看到binding readdir的第4个参数是kUsePromises，表明是个异步的处理。

       当传递了recursive参数时，将调用readdirRecursive，而readdirRecursive的代码与readdirSyncRecursive的大同小异，有兴趣的可以读一读：

       fs.js的提交记录

       我们搜索readdir的提交记录，能发现这两篇都与深度遍历有关：

       其中 下面的这个，正是我们这次问题的罪魁祸首。

       刚才看到的fs.js中的readdirSyncRecursive里这段长长的注释，正是这次提交里添加的：

       从代码对比上，我们就能看出为什么我们的代码遍历的程序为2了，因为readdirResult是个二维数组，它的长度就是2啊。取它的第一个元素的长度才是正解。坑爹！

       也就是说，如果不使用withFileTypes这个参数，得到的结果是没有问题的：

       发版记录

       我们在Node.js的发版记录中，找到这条提交记录，也就是说，v..0才修复这个问题。

       而Electron只有Node.js更新到v后，这个功能才修复。

       而从Electron与Node.js的版本对应上来看，得更新到v了。

       只是需要注意的是，像前文提过的，如果是遍历的是当前项目的内置文件，Electron并没有支持这个新的参数，在打包后会出现Bug。

       fs的同步阻塞

       其实有人提过一个 issue：

       确实是个风险点。所以，建议Node.js开发者老老实实使用fs/promises代替fs，而Electron用户由于坑爹的fs包裹，还是不要用这个特性了。

       总结

       本次问题的起因是我的一个Electron项目，使用了一个Node.js fs API的一个新参数recursive递归遍历文件夹，偶然间发现返回的文件数量不对，就开始排查问题。

       首先，我选择了升级Electron的包版本，发现从v.0.4升级到最新版本v.1.0后，问题解决了。但由于发版在即，不能冒然升级这么大件的东西，所以先使用readdirp这个第三方包处理。

       接着排查问题出现的原因。我到Electron的GitHub上搜索issue，只找到一条近期的提交，但看提交信息，不像是我们的目标。我注意到这条提交的修改文件（asar-fs-wrapper.ts），是Electron针对Node.js的fs API的包装，意识到这是Electron为了解决打包前后内置文件路径的问题，心血来潮之下，将其中核心代码简化后，测试发现问题出在fs.promises readdir的重写上，继而锁定了Node.js版本v..1的fs.readdir有Bug。

       下一步，继续看Node.js的源码，确定了fs.promises与fs是两套不同的实现，不是简单地使用util.promisify进行转换。并在fs的代码找到关于recursive递归的核心代码readdirSyncRecursive。又在提交记录里，找到这段代码的修复记录。仔细阅读代码对比后，找到了返回数量为2的真正原因。

       我们在Node.js的发版记录中，找到了这条记录的信息，确定了v..0才修复这个问题。而内嵌Node.js的Electron，只有v版本起才修复。

       不过需要注意的是，如果是遍历的是当前项目的内置文件，由于Electron并没有支持这个新的参数，在打包后会出现Bug。而且由于fs.readdir使用recursive时是同步的，Electron重写的fs.promises readdir最终调用的是它，可能会有隐性的性能风险。

       本次定位问题走了些弯路，一开始将目标锁定到Electron上，主要是它重写fs的锅，如果我在代码中用的fs.readdirSync，那么可能会更早在Node.js上查起。谁能想到我调用的fs.promises readdir不是真正的fs.promises readdir呢？

       最后，针对此次问题，我们有以下启示：

       PS：我给Electron提了个 issue，一是让他们给fs.readdir添加recursive参数的实现，二是让他们注意下重写时fs.promises readdir的性能风险。