1.抽丝剥茧：Electron与Node.js的判断奇葩Bug
2.如何判断小程序是原生开发还是uniapp开发
3.什么是原生代码
4.如何判断小程序是原生开发还是uniapp开发？
抽丝剥茧：Electron与Node.js的奇葩Bug
起因是最近在用Electron开发一个桌面端项目，有个需求是源码原生源需要遍历某个文件夹下的所有JavaScript文件，对它进行AST词法语法分析，看源解析出元数据并写入到某个文件里。全开需求整体不复杂，判断只是源码原生源mobileimsdk源码细节有些麻烦，当我以为开发的看源差不多时，注意到一个匪夷所思的全开问题，查的判断我快怀疑人生。
缘起
什么问题呢？
原来这个需求一开始仅是源码原生源遍历当前文件夹下的文件，我的看源获取所有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的性能风险。
如何判断小程序是原生开发还是uniapp开发
判断小程序是原生开发还是使用了UniApp开发可以根据以下几个方面来进行判断：1.代码结构和文件类型：原生开发的小程序通常使用各个平台提供的开发工具和框架进行开发，代码结构和文件类型与具体平台相关。而使用UniApp开发的小程序，代码结构和文件类型相对统一，包含了一套跨平台的代码。
2.开发工具：原生开发的小程序使用各个平台提供的官方开发工具进行开发，如微信开发者工具、支付宝小程序开发工具等。而使用UniApp开发的小程序，则使用HBuilderX等开发工具。
3.语言和框架：原生开发的小程序使用各个平台提供的编程语言和框架进行开发，如微信小程序使用的是JavaScript和微信小程序框架。而UniApp开发的小程序可以使用Vue.js作为主要的开发语言和框架。
4.跨平台能力：UniApp是一个基于Vue.js的跨平台开发框架，可以同时开发微信小程序、支付宝小程序、百度小程序、头条小程序等多个平台的小程序。如果一个小程序同时发布在多个平台上，那么它很可能是使用UniApp开发的。
需要注意的是，判断小程序的开发方式最准确的方法是查看开发者的源代码或了解开发者的开发过程。通过观察代码结构、开发工具和使用的语言框架等方面的特点，可以推测小程序的开发方式。
以上内容是由猪八戒网精心整理，希望对您有所帮助。
什么是原生代码
原生代码是计算机编程(代码)，编译为与特定处理器(例如 Intel x 级处理器)及其指令集一起运行。如果在具有不同处理器的计算机上运行相同的程序，则可以提供软件以使计算机模拟原始处理器。在这种情况下，原始程序在新处理器上以“仿真模式”运行，并且几乎肯定比原始处理器上的本机模式慢。 (该程序可以重写并重新编译，以便它以纯模式在新处理器上运行。)
本机代码也可以与字节码(.高级语言编译，链接，其实是实现以下过程： 源代码---->汇编----->机器指令 对否？ 不一定， 汇编语言－汇编－机器指令 C/C++语言－编译－机器指令 VB6、Java、.NET－编译－对应的P代码 2.可以把机器指令，变成汇编指令么？ 不应叫“变成”，应该叫“以汇编助记符的形式呈现”
如何判断小程序是原生开发还是uniapp开发？
小程序是否是使用 uni-app 开发的，可以通过以下方式来判断：查看项目的文件结构。uni-app 项目的文件结构与传统的小程序项目不同，它有一个独特的 /src 目录。
查看项目中是否有 uni.js 文件。uni-app 会在小程序项目中自动生成一个 uni.js 文件，该文件是 uni-app 的核心文件之一。
查看项目的配置文件。uni-app 会在项目根目录下生成一个 uniapp.config.js 的文件，该文件包含了 uni-app 项目的各种配置信息。
如果你的小程序项目中有以上三个特征，那么它很可能是使用 uni-app 开发的。
当然，也有可能是使用 uni-app 开发，但是将 uni.js 文件和 uniapp.config.js 文件删除或者重命名了，这时就需要进一步检查项目的文件内容，寻找其它的指示性信息了。
